Introdução ao Git e GitHub

Quando eu falo que levou quase 10 anos de carreira para eu precisar usar o Git e o GitHub pela primeira vez os devs mais novos estranham, mas é verdade. Durante quse 10 anos eu trabalhei exclusivamente com stack .NET da Microsoft e, portanto, usava inicialmente o Visual Source Safe para versionamento de código (terrível, diga-se de passagem) e mais tarde o Team Foundation Server (TFS, bom, mas lento). Antes disso eu cheguei a usar brevemente o Tortoise SVN, que também era um pé no saco e acho até que já tinha baixado o zip de um ou outro repositório no GitHub, mas sem interagir com o software do Git em si.

No entanto, de 2015 pra cá o GitHub se tornou um fenômento, com a própria Microsoft comprando o mesmo e usando-o pesadamente para treinos de modelos de IA, como o GitHub Copilot e integrando-o nativamente às suas ferramentas como Visual Studio e Visual Studio Code. Quando troquei definitivamente de stack, de .NET para JS, não deu mais para ignorar e ele passou a fazer parte do dia a dia.

Atendendo a pedidos, vou iniciar uma série de artigos aqui no site ensinando o básico para sobreviver ao uso de Git e GitHub, visando ajudar quem estiver começando com eles e principalmente, quem precisa aprender para uso no trabalho. Existem conhecimentos diferentes que são necessários quando apenas estamos usando Git par auso próprio e quando estamos usando em times, no ambiente profissional, sendo que vou focar neste segundo. Depois, o conhecimento mais avançado vem com a prática mesmo, não adianta querer aprender com tutoriais eternamente.

Vamos lá!

#1 – O que é Git e GitHub

Começando do básico e resolvendo uma confusão comum: Git e GitHub não são a mesma coisa.

O Git é um software para versionamento distribuído de arquivos, geralmente códigos-fonte de outros softwares. Foi criado e distribuído livremente por Linus Torvalds (mesmo criador do Linux) em 2005, ganhando popularidade rapidamente. Com ele, times conseguem fazer alterações em arquivos de maneira que mantém histórico de versões, resolução de conflitos, possibilidade de rollbacks, merges, forks e muito mais. Via de regra, através de comandos no terminal, mas há também ferramentas visuais e plugins para IDEs famosas, como Visual Studio Code. Você pode subir um servidor de Git em qualquer máquina, incluindo a sua, e começar a trabalhar colaborativamente nos projetos inicializados com ele.

Já o GitHub é um serviço de Git na nuvem, onde você consegue criar os repositórios de código-fonte e compartilhá-los com pessoas do mundo inteiro muito mais facilmente, fornecendo uma interface web para tal. Criado em 2008 por alguns amigos e mais tarde vendido para a Microsoft em 2018, é hoje a principal referência quando o assunto é serviço online de versionamento de código, principalmente por possuir uso gratuito para a maior parte dos cenários e funcionalidades que você pode precisar.

Ou seja, enquanto Git é um software local, o GitHub é como se fosse a sua versão online. Embora existam algumas diferenças na experiência de usar o Git localmente ou na nuvem, os mesmos conhecimentos se aplicam.

#2 – Ambiente

O primeiro passo é baixar e instalar o Git na sua máquina, independente se vai usá-lo com GitHub ou não. Você pode fazer isso pelo site oficial, baixando o instalador e executando até o final.

Depois, recomendo criar uma conta gratuita no GitHub, para poder criar repositórios Git online. Você pode fazer isso pelo site do GitHub, nenhuma instalação é necessária.

Você vai precisar também de uma IDE ou Code Editor para realizar as dinâmicas de escrita de código, recomendo o Visual Studio Code, que você pode baixar no site oficial da ferramenta.

Precisando de ajuda com estas instalações, o vídeo abaixo mostra o passo a passo.

Com o ambiente instalado, configure a sua conta do GitHub na máquina local usando o seguinte comando no terminal, ajustando o conteúdo das variáveis de acordo.

Isso vai deixar a sua máquina configurada globalmente com as suas credenciais, algo necessário para as tarefas a seguir.

#3 – Conceitos Básicos

Boa parte dos conceitos mais fundamentais de uso de Git + GitHub + VS Code eu abordei no vídeo abaixo, pode usar ele ao invés de ler. Mais tarde, abordaremos conceitos mais intermediários, aí volte ao texto ou procure novo vídeo.

Independente se você está entrando em uma nova empresa com um projeto já existente ou criando um projeto do zero para uma, o primeiro passo que você vai ter de fazer é clonar o repositório do projeto na sua máquina. Se você ainda não tem um repositório criado, vá na sua conta do GitHub e use o botão verde de New para criar um. O preenchimento dos campos do repositório são bem autoexplicativos, mas destaco a importância de ter cuidado com a visibilidade do repositório, prefira deixá-lo privado caso seja o projeto de um cliente ou empresa.

Agora tendo o repositório criado por você ou criado por qualquer outra pessoa, é hora de clonar ele na sua máquina, o que você pode fazer tanto visualmente pelo VS Code quanto via linha de comando no terminal. No vídeo que citei acima mostro como fazê-lo de maneira visual, então aqui vou mostrar via linha de comando. Pegue o endereço completo do seu repositório no GitHub e use o seguinte comando para cloná-lo:

Isso vai criar uma pasta com o nome do repositório e seu conteúdo dentro. Aí dentro desta pasta, manualmente ou pelo editor de código, crie dois arquivos quaisquer. Minha recomendação: criar um HTML e um JS, com olá mundo dentro deles, apenas para exemplo. Quando adicionar arquivos dentro da pasta do repositório, eles vão estar sendo monitorados pelo Git. Isso se torna óbvio se estiver usando o VS Code, pois ele tem uma aba específica para trackear mudanças no repositório, mas também é possível de observar via terminal, usando o comando abaixo dentro da pasta do projeto.

Veja abaixo o resultado no meu caso.

Neste exemplo, o Git está dizendo algumas coisas:

• estou trabalhando na branch “main” (principal);
• minha branch é a mais atual;
• tenho arquivos não versionados (untracked): index.html e script.js;
• não adicionei nada para o novo commit, mas tem arquivos não versionados presentes;

Aqui temos alguns jargões bem comuns no mundo Git e também a sugestão de usar “git add” para versionar os arquivos untracked, mas já falaremos sobre isso. Sobre os jargões, alguns que já apareceram:

• repositório: o seu projeto criado no Git;
• branch: ramificação ou snapshot (como preferir chamar) do repositório;
• main: ramificação/branch principal do projeto, a “verdadeira”, geralmente a cópia que está em produção, podendo haver outras em paralelo;
• untracked: arquivos ainda não versionados (salvos localmente, mas não no repositório);
• commit: nova versão dessa branch (com um ou mais arquivos novos ou alterados) ;

Atenção especial aqui a branches e commits. Branches são variações do seu projeto, cópias dele com histórico próprio, sendo que ao menos ele terá uma, a main. O Git permite que diversas branches existam para um mesmo repositório, permitindo o desenvolvimento em paralelo sem um desenvolvedor atrapalhar o outro. Mais tarde, branches podem ser fundidas (merge) para se tornarem apenas uma novamente.

Já os commits são os milestones ou marcos históricos das branches. Como se fossem as versões do projeto naquela branch e que uma vez criados, habilitam-nos navegar pelas diferentes versões. Cada commit guarda todas as alterações que o projeto sofreu naquele momento da sua vida, incluindo linhas alteradas, arquivos adicionados ou removidos e muito mais. Um arquivo novo por exemplo, como os que você criou por último, só passam a existir após serem commitados (committed) em alguma branch e é o que faremos a seguir.

Conforme forem aparecendo, explicarei outros jargões mais à frente.

#4 – Versionando Arquivos

O processo de versionar um ou mais arquivos em um repositório Git passa pelas seguintes etapas: Desenvolvimento > Staging > Commit. Uma vez que você tenha desenvolvido e salvo seu arquivo corretamente, você deve adicioná-lo na Staging Area antes do Commit, algo como uma “área de preparação”. O comando para adicionar um arquivo na staging é:

Você pode usar o comando acima, arquivo por aquivo. Agora caso queira adicionar todos os arquivos alterados/adicionados na pasta atual do terminal, você pode usar o atalho abaixo.

Agora se você rodar o comando “git status” novamente na pasta raiz do repositório, terá um resultado parecido com esse.

Note que agora além de dizer a branch que você está e que ela está atualizada, há informação de alterações (change) a serem commitadas no repositório. Ou seja, tem coisa pronta para ir pra uma nova versão (commit) na branch. Quais alterações? Elas estão em verde: dois novos arquivos foram adicionados ao projeto, mas caso queira desistir de algum deles, o terminal lhe sugere usar o comando abaixo.

Outra opção para voltar atrás é o git restore, que foca mais em desfazer alterações dentro de arquivos.

Uma vez que você tenha arquivos na staging area, eles estão preparados para serem parte de um novo commit. Ao realizar o comando de commit, gera-se uma nova versão do projeto (ainda local) com tudo que estava na staging area. Para ajudar a organizar os commits, é exigido que seja informada uma commit message que simbolize aquele conjunto de alterações: “bugfix A”, “feature B”, etc.

Uma confirmação do commit será impressa se tudo der certo, com um resumo do que foi incluído nesse commit.

Repare duas informações importantíssimas logo no topo: [main f894a8b]. Isso indica a branch onde commitamos (main) e o id do commit (f894a8b). Cada commit ganha um id único e é a partir dele que conseguimos depois entender o que foi alterado neste momento do tempo nesta branch.

Agora se você rodar um “git status” novamente, terá como resultado:

Note como cita que nossa versão local está adiantada (ahead) em relação à origin/main (versão original principal do repositório) em 1 commit. A sugestão nesse caso é que faça um comando para enviar nosso commit para o repositório remoto. Por fim, a mensagem cita que não há nada novo para commitar.

Se você for lá na página do seu repositório no GitHub notará que nada mudou. Mesmo você fazendo alterações ou adicionando arquivos, fazendo o staging deles e depois o commit, essa nova versão não foi parar o repositório online. Isso porque fizemos tudo localmente e agora é hora da última etapa: enviar para o repositório online, ou mehor, “empurrar” (push) com o comando abaixo.

O git push quando feito com sucesso, apresenta uma mensagem como abaixo.

Aqui nós temos uma contagem de objetos enviados, dados sobre compressão, escrita e onde tudo foi parar: no meu repositório online, indicando ainda o hash do commit, em qual branch eu estava e para qual eu fui (main). É isso que esperamos de um push bem sucedido. Se você ir lá olhar no GitHub agora, vai estar lá o nosso novo commit e suas respectivas alterações. Vamos explorar melhor a interface do GitHub em outro momento, por enquanto, explore por sua conta.

No entanto, caso o repositório não seja seu, pode ser que você tenha um erro de falta de permissão. Aí a pessoa que é dona do repositório tem de lhe adicionar como colaborador do projeto.

Na próxima etapa, vamos falar mais sobre branches, checkouts e merges. Disponível neste link.