Imagine que você já cursou algumas disciplinas do seu curso e nelas você desenvolveu alguns projetos, fez um curso de Python ou de marketing, aprendeu gestão financeira ou desenvolveu um projeto pessoal super legal no semestre passado.
Aí, em uma entrevista de emprego, em uma seleção de estágio ou até numa conversa de networking, alguém te pergunta:
E, nesse momento... vem aquele branco. Ou você lembra que o código está solto em uma pasta no seu computador chamada projeto_final_vesao999_agora_vai, ou o projeto que você levou horas fazendo está lá pedido no Drive talvez, e nada do que você produziu está pronto para ser compartilhado.
O resultado? Fica a falsa impressão de que você não tem experiência nenhuma, quando na verdade você trabalhou, estudou e produziu bastante! O problema não é a falta de conhecimento ou dedicação, é a invisibilidade da sua produção.
Tudo o que você faz e aprende fica guardado em "gavetas digitais" onde ninguém consegue ver.
É exatamente para resolver esse problema que estamos aqui no minicurso Portfólio 4.0: Introdução à Organização de Projetos e Visibilidade com GitHub!
Hoje, vamos aprender como transformar esses trabalhos escolares, produções acadêmicas e projetos pessoais em uma vitrine digital organizada, profissional e visível utilizando o mesmo padrão de registro e versionamento adotado pelo mercado global.
Não se trata apenas de salvar arquivos na nuvem, mas de construir o seu histórico de evolução, demonstrar suas competências de forma clara para recrutadores e dar a visibilidade que o seu trabalho merece.
Vamos tirar seus projetos da gaveta! 🚀
Antes de começarmos, vamos entender as fundações de onde vamos trabalhar: o que é o Git, o que é o GitHub e qual é a diferença entre eles?
O GitHub é uma plataforma que permite hospedar, organizar, documentar, compartilhar e colaborar em projetos, inclusive em projetos open source (código aberto), nos quais o código é disponibilizado para que outras pessoas possam conhecer, utilizar, modificar e contribuir com o projeto, de acordo com suas regras de licença e colaboração.
Um dos principais recursos do GitHub são os repositórios, que funcionam como espaços onde um projeto pode ser armazenado, desenvolvido e apresentado. Além de armazenar repositórios, o GitHub oferece recursos para organização, documentação, colaboração, automação e publicação de projetos.
Neste workshop, utilizaremos principalmente:
O Git é um programa que roda direto no seu computador. Ele funciona como uma máquina do tempo para os arquivos do seu trabalho. Imagine um Trabalho Acadêmico em Equipe: cada vez que você escreve uma seção e salva, o Git cria um Commit (uma foto do estado atual do texto). Se você fizer uma alteração e depois quiser recuperar o código ou o texto anterior, pode olhar os commits antigos e recuperar o arquivo voltando ele ao estado original porque você vai ter “fotos” de todos os diferentes momentos do desenvolvimento.
💡 Nota do Nosso Minicurso: Como o nosso objetivo aqui na VI SciTec é documentar a produção acadêmica diretamente no GitHub, nós não vamos usar o Git no computador hoje, mas é fundamental que você conheça a existência dele e saiba que Git e GitHub não são a mesma coisa.
Para mandar a sua parte do trabalho para a internet, ou trazer a parte que os seus colegas fizeram para o seu computador, você usa dois comandos principais:
🏢 Grandes Empresas que Usam o Git e o GitHub: Esta tecnologia não é apenas para estudantes. Ela é o padrão absoluto do mercado global. Gigantes da tecnologia como Microsoft, Google, Meta (Facebook/Instagram), Netflix, Amazon, NASA e Spotify utilizam o Git e o GitHub diariamente para gerenciar seus códigos privados e para disponibilizar seus grandes projetos de código aberto (open source) para a comunidade global. Aprender isso agora é usar a mesma ferramenta que os melhores engenheiros de software do mundo usam.
Antes dos sistemas de controle de versão distribuídos, controlar as alterações de um projeto desenvolvido por várias pessoas já era um desafio.
Alguém escrevia a Introdução e mandava por e-mail. Outra pessoa baixava o arquivo, alterava a Metodologia e salvava como Trabalho_Final_V99. Uma terceira pessoa fazia mais algumas alterações e surgia o Trabalho_Definitivo_Atualizado.
No meio de tanta troca, era fácil perder o controle:
Imagine isso acontecendo em uma equipe de desenvolvimento mundial.
Para organizar esse problema, surgiram os sistemas de controle de versão. Entre eles, havia sistemas centralizados, nos quais o projeto ficava associado a um servidor central. Em alguns desses sistemas, um arquivo podia ser bloqueado enquanto uma pessoa trabalhava nele, impedindo alterações simultâneas.
Isso resolvia alguns conflitos, mas também podia criar filas e limitar a forma como as pessoas colaboravam.
Com o surgimento dos sistemas de controle de versão distribuídos (DVCS), o modelo mudou. Em vez de depender exclusivamente de um servidor central, cada participante podia ter uma cópia do repositório e de seu histórico, trabalhar de forma independente e depois sincronizar as alterações.
É aqui que a história fica interessante.
Em 1991, Linus Torvalds iniciou o desenvolvimento do Linux. O projeto cresceu e passou a receber contribuições de pessoas de diferentes lugares do mundo.
O desenvolvimento do Linux também cresceu rapidamente. Durante seus primeiros anos, de 1991 a 2002, as alterações eram compartilhadas principalmente como patches (arquivos que descreviam as alterações a serem aplicadas ao código) e arquivos compactados.
À medida que o projeto crescia e mais pessoas participavam, tornou-se necessário utilizar ferramentas mais adequadas para controlar e organizar esse desenvolvimento.
Em 2002, o projeto do kernel Linux começou a utilizar o BitKeeper, um sistema de controle de versão distribuído (DVCS).
Ou seja: o Git não inventou o conceito de controle de versão distribuído. O BitKeeper já utilizava esse modelo antes do Git existir. A experiência com essa ferramenta também ajudou a mostrar quais características eram importantes para o desenvolvimento de um projeto enorme e distribuído como o Linux.
Em 2005, a relação entre a comunidade que desenvolvia o kernel Linux e a empresa responsável pelo BitKeeper se rompeu. Com o fim dessa relação, a autorização que permitia o uso gratuito da ferramenta foi revogada. A documentação oficial do Git descreve o rompimento de forma breve, sem apresentar uma única causa oficial para ele.
O BitKeeper era uma ferramenta proprietária, enquanto o kernel Linux era um projeto de código aberto. Essa diferença fazia parte do contexto da relação entre a ferramenta e a comunidade, mas não é correto reduzi-la, por si só, a uma única causa para o rompimento.
O fato é que a comunidade precisava de outra solução.
Foi nesse contexto que Linus Torvalds e outros desenvolvedores criaram o Git em 2005.
A ideia era desenvolver uma ferramenta que atendesse às necessidades específicas do projeto: ser rápida, simples, totalmente distribuída e capaz de lidar eficientemente com um projeto muito grande, além de oferecer forte suporte ao desenvolvimento não linear, com várias linhas de desenvolvimento acontecendo em paralelo.
O Git também surgiu como uma alternativa livre e de código aberto, adequada ao contexto de desenvolvimento do kernel Linux, aproveitando os aprendizados obtidos com o BitKeeper e com as ferramentas que já existiam.
O Git já permitia controlar versões e trabalhar de forma distribuída, mas ainda havia espaço para facilitar o compartilhamento e a colaboração pela web.
Foi nesse contexto que surgiu o GitHub, fundado em 2008.
A plataforma passou a oferecer uma interface web para hospedar repositórios Git, compartilhar projetos, documentar trabalhos e colaborar com outras pessoas.
O próprio GitHub também é desenvolvido usando Git. O primeiro commit no repositório do GitHub foi realizado em 19 de outubro de 2007, antes da fundação da empresa em 2008. O próprio GitHub registrou essa data em seu blog ao completar seu primeiro ano.
Hoje, o GitHub se apresenta como uma plataforma para desenvolver, compartilhar e colaborar em projetos de software, com a comunidade open source como uma parte importante de seu ecossistema.
Hoje, pularemos o uso do Git e os comandos de terminal de computador. Entraremos direto no site do GitHub para construir um ecossistema conectado.
Conta → Perfil (Profile README) → Repositório de Projeto → Wiki (Documentação) → Markdown (Navegação).
## Título para subtítulos ou [Texto do link](endereço) para links). É através do Markdown que faremos a conexão de navegação do ecossistema: criando links no seu Perfil para direcionar ao Repositório de Projeto, e do projeto direcionando para a Wiki. Não é necessário saber HTML ou Markdown de cor: podemos transformar textos rapidamente com a ajuda da IA e, depois, revisar o resultado.