Git e GitHub

• O que é Git
• Onde o GitHub entra nessa história
• Como isso se encaixa no dia a dia de uma pessoa desenvolvedora
  • Concluir as configurações necessárias
  • Iniciar o projeto com o Git
  • Atuar no projeto
  • Salvar minhas alterações
  • Juntar o código novo com o código principal
  • Atualizar o projeto local
• Resumindo

O que é Git

Segundo nossa querida Wikipedia, o Git é um sistema de controle de versões distribuído.

E o que isso significa?

Deixa eu tentar explicar com um exemplo:

Suponha que estamos trabalhando em uma plataforma muito grande, onde funcionalidades são atualizadas e criadas constantemente. Em determinado momento alguém fala para apagarmos uma funcionalidade que era difícil de manter e não estava sendo usada. Fazemos isso, simplificamos bastante coisa no nosso código e seguimos criando e atualizando outras coisas. Meses se passam e um belo dia alguém fala que vai precisar daquela funcionalidade que apagamos. E agora?

Se nosso projeto estiver usando o Git, podemos voltar na ramificação que tinha aquela funcionalidade (aquele “controle de versão” da definição da Wikipedia) e pensar em estratégias para integrar esse código apagado novamente. Não seria necessário criar tudo do zero.

Com o Git, cada pessoa que tiver clonado o repositório terá uma cópia local do histórico completo da versão do projeto. Alterações podem ser feitas na sua máquina e enviadas para o repositório principal depois, assim várias pessoas podem atuar no projeto ao mesmo tempo (inclusive no mesmo arquivo) sem que uma alteração afete os outros.

Onde o GitHub entra nessa história

O GitHub é uma plataforma que usa Git. É como se alguém tivesse baixado o Git em um servidor, feito uma tela maneira, colocado algumas funcionalidades a mais e disponibilizado em nuvem pra gente usar. Assim como o GitHub, existem várias outras plataformas que usam o Git por trás dos panos, como o GitLab e Bitbucket.

Como isso se encaixa no dia a dia de uma pessoa desenvolvedora

Falando sobre o meu dia a dia enquanto desenvolvedora, muita coisa gira ao redor do Git / GitHub.

Concluir as configurações necessárias

Após instalado, precisamos configurar o Git. Sua configuração inicial precisa incluir o nome e email da autoria de mudanças enviadas por determinada máquina.

git config - as configurações do Git precisam ser feitas apenas uma vez se usarmos a opção --global ou por diretório se usarmos a opção --local. Existe uma lista enorme de coisas que podemos configurar, mas as principais são o nome (git config --global user.name "Seu Nome") e email (git config --global user.email "[e-mail]")

Iniciar o projeto com o Git

Logo que começo a atuar em um projeto, uma das primeiras coisas a fazer é clonar o repositório e ler as instruções (normalmente encontradas no arquivo README.md na raiz do projeto).

git clone url_do_projeto - clonar um projeto significa fazer uma cópia do repositório na minha máquina, para que eu possa acessá-lo e atuar nele localmente. Normalmente é uma ação feita apenas uma vez por projeto.

O GitHub tem uma documentação boa sobre como clonar projetos. A minha opção preferida é clonar via SSH já que não preciso ficar validando minha identidade repetidamente. O GitHub também tem uma documentação detalhando como isso funciona.

Caso seja um projeto 100% novo, posso criar a base dele na minha máquina para então iniciar o Git localmente e enviar para o repositório no GitHub.

git init - iniciar um repositório também costuma ser uma ação feita apenas uma vez. Esse comando vai criar uma pasta chamada .git na raiz do projeto contendo todos os metadados do repositório e habilitar o uso dos demais comandos do git para aquele projeto.

Para criar o repositório no GitHub, basta seguir a documentação deles que não tem muita surpresa.

Atuar no projeto

Uma vez que tenho o código disponível na minha máquina, posso começar a atuar em alterações. Para isso crio uma nova ramificação (ou branch) a partir da ramificação principal, normalmente chamada de main.

Um branch é um snapshot do código em determinado momento, uma "cópia" isolada do código tal qual está. Dessa forma podemos testar coisas, mudar comportamentos, etc, sem que nossas ações afetem as demais versões do projeto.

git checkout -b minha-tarefa - o comando git checkout, quando usado dessa forma, é responsável por mudar de branch; a opção -b criará um novo branch com o nome informado a seguir (nesse exemplo, minha-tarefa).
Vale comentar aqui que o -b veio como uma forma de chamar o comando git branch (que lista, cria, renomeia e exclui branches) junto ao git checkout.

Salvar minhas alterações

Gosto de separar meu desenvolvimento em fases. Então assim que termino partes do que estou fazendo posso "nomear" aquele pacote de alterações e criar um histórico de coisas que executei.

git add [nome dos arquivos] - primeiro é necessário falar quais arquivos vou incluir em determinado "pacote" de alteração, seja colocando o nome dos mesmos separados por espaço (ex.: hello.html hello.css), seja usando um . para incluir tudo de determinado diretório, ou --all para adicionar todos os arquivos alterados em todos os diretórios.

git commit -m "uma mensagem" - depois de ter todos os arquivos selecionados, preciso adicionar uma mensagem que explica a alteração que foi feita.

Usando esses comandos, se alguma alteração que fiz der errado, posso consultar o histórico do meu branch e voltar para determinado ponto do desenvolvimento, se necessário for.

Bem, até então tudo o que foi desenvolvido está apenas na minha máquina e preciso enviar isso para o GitHub (ou qualquer outra plataforma que estiver usando). Normalmente costumo enviar as alterações que fiz ao final do dia (vai que minha máquina pega fogo, nunca se sabe...) ou quando o desenvolvimento está concluído.

git push origin minha-tarefa - aqueles commits que fiz anteriormente serão "empurrados" do branch minha-tarefa da máquina local para o ambiente remoto (o repositório "origem" no GitHub), em um branch que também será chamado de minha-tarefa.

Dá pra usar o comando git push de algumas formas diferentes. Achei um artigo da Trybe muito maneiro que entra em mais detalhes, caso queira.

Juntar o código novo com o código principal

Uma vez que terminei tudo o que tinha para fazer naquela tarefa posso abrir um Pull Request (ou PR). Em resumo, o PR vai disponibilizar o código que eu criei para ser revisado por outras pessoas que trabalham comigo (e por mim mesma também) e, caso esteja tudo certo, juntá-lo ao código principal (ação chamada merge).

Na imagem estamos abrindo um Pull Request no GitHub. Queremos juntar nosso código no código principal, então configuramos a base como main (o branch principal) e comparamos com o branch que atuamos, minha-tarefa. Para que as outras pessoas saibam o que aquele PR trata, colocamos um título resumindo a tarefa que estamos entregando e uma descrição explicando o objetivo daquele código, dando exemplos de como testar, adicionando detalhes importantes sobre as regras que aquele código deve seguir, etc.

O GitHub tem uma documentação bem detalhada sobre como funciona esse processo. Existem várias customizações que podem ser feitas, é bem legal.

Atualizar o projeto local

Uma vez que terminei minhas alterações, preciso voltar para o branch principal e buscar a versão mais atual dele, para, só então, começar a trabalhar em uma nova tarefa.

git checkout main - usado para voltar ao branch principal. Aqui não é necessário usar a opção -b pois a ramificação main já existe.
git pull origin main - "puxa" para a máquina local todas as alterações que estiverem no branch main da origem, o repositório no GitHub.

Resumindo

É difícil colocar todos os comandos do Git em um único post, mas esses são os principais do meu dia a dia. Vou deixar um resumo para download pra facilitar o acesso:

• Baixar como PDF
• Baixar como imagem

Se aparecer qualquer dúvida pode colocar aqui nos comentários que tento responder assim que possível.

Até a próxima!