Hello Git: Um tutorial para usar o Git imediatamente

Quem nunca fez uma cópia de um arquivo que desejava alterar (só pra garantir)? Fazemos isso tanto para um código de programa quanto para algum outro tipo documento. O Git mantém essas cópias de forma mais eficiente e organizada. Com o Git, uma equipe consegue trabalhar em diferentes funcionalidades simultaneamente. As cópias só guardam o que foi alterado de uma versão do documento para a outra. Por isso é mais eficiente. O Git te ajuda mesmo que você esteja trabalhando sozinho.

Pessoalmente, várias vezes eu testei alguma alteração em um programa que estava desenvolvendo, e algumas vezes essa alteração saiu muito errada. Não precisei me desesperar. Simplesmente descartei todas as alterações e o programa voltou a funcionar como antes. Mas nem sempre foi assim. Eu mesmo já usei o Git como um simples cliente para enviar e fazer o download do meu código no GitHub como se fosse apenas um backup. Muitas vezes eu precisei excluir o repositório local e baixá-lo novamente. Fiz isso por que eu não conhecia nem os comandos básicos do Git. Espero que você, após ler este livro, não precise cometer os mesmos erros que eu cometi.

Como já mencionado, Git é um programa que gerencia as versões de arquivos com código fonte de programas e outros documentos. O GitHub é uma plataforma de hospedagem de código que, como o nome já deixa claro, usa o Git como interface de interação. É uma das plataformas mais usadas e famosas. Porém, existem outras como Bitbucket e Gitlab. Neste livro, os exemplos com repositórios remotos serão com o Github. Mas os conceitos são os mesmos para qualquer plataforma de hospedagem que use o Git como interface de interação. O que muda entre as plataformas de hospedagem de código são alguns detalhes da interface web de cada serviço. Também muda o que cada plataforma oferece para seus usuários. Por exemplo, duas ferramentas que eu acho muito úteis no GitHub é o GitHub Pages e o GitHub Actions. Minha página pessoal é hospedada no GitHub pages. Estou usando o GitHub Actions para renderizar este livro toda vez que faço uma atualização no servidor. Acredito que, caso você tenha interesse em usar uma plataforma de hospedagem de código, as informações contidas aqui serão suficientes para você escolher a plataforma que se adequa melhor às suas necessidades.

Este livro foi pensado para quem nunca teve contato com o Git e nem sabe direito o que ele é. Mas se você já tem uma noção, ou já usou o Git de alguma forma, a figura 1 mostra uma sugestão de como ler este livro.

O capítulo 2 (Iniciando um repositório local) mostra como criar um repositório no seu computador a partir de um diretório. Como criar um repositório no GitHub e utilizá-lo no seu computador é mostrado no capítulo 3 (Repositório remoto no GitHub). No capítulo 4 (Criando fotografias novas e acessando fotografias antigas) é mostrado como criar versões e acessar versões anteriores. Veremos como trabalhar simultaneamente com versões diferentes de um programa no capítulo 5 (Ramos no projeto). Você verá o mínimo necessário para mesclar bifurcações no capítulo 6 (Criando bifurcações no projeto). O capítulo 7 (Conclusão) reforça o que foi mostrado nos demais capítulos e sugere obras para você continuar seu aprendizado.

Neste livro, tudo será apresentado pela linha de comando. O mais importante é entender os conceitos e o motivo de se usar cada comando. Sem estes conceitos uma interface gráfica é inútil. Por isso, acredito que pela linha de comando você entenderá o necessário para usar uma interface gráfica posteriormente. Além disso, os comandos de terminal são os mesmos para Windows, Linux e Mac. Você encontra como instalar o Git em seu computador no endereço Instalando o Git (https://git-scm.com/book/pt-br/v2).

Um comando que é usado o tempo todo em um repositório Git é o comando git status, apresentado na lista de comandos 3. Apesar desse comando estar em uma seção dedicada a ele, devido a sua importância, ele não será abordado em profundidade, uma vez que nosso objetivo aqui é mostrar uma utilização do Git com poucos comandos, sem explorá-los por completo.

Como pode ser traduzido da terceira linha de resposta da lista de comandos 3, o Git monitora (track) arquivos criados ou copiados para dentro do diretório do repositório. A lista de comandos 4 mostra o conteúdo que queremos no arquivo greet.py. Este arquivo em texto simples pode ser criado dentro do diretório ou copiado para dentro dele. É um arquivo escrito na linguagem de programação Python 3. Porém, não é necessário saber Python para acompanhar este tutorial. Basta notar que o arquivo será alterado e cada alteração será monitorada pelo Git.

Depois de criado o arquivo greet.py, o comando git status mostrará uma resposta um pouco diferente, como mostra a lista de comandos 5. Apenas as duas primeiras linhas cntinuam iguais.

Aqui é um ponto que merece uma atenção especial quando se usa o Git. O Git só "fotografa" (commit) as alterações que estão em uma área abstrata de sua organização chamada stage. Isso por que, muitas vezes fazemos alterações que não queremos gravar. Testamos algo, não gostamos do resultado, e queremos descartar o que foi feito. Outras vezes, queremos gravar só algumas alterações, mas não todas. Esse processo também nos permite fazer alterações variadas e agrupá-las em fotografias separadas.

A lista de comandos 6 mostra como adicionar um arquivo na área de stage do Git, com o comando git add greet.py. Note que agora o arquivo está sendo monitorado, mas ainda não foi "fotografado" (committed). Se você colocar um arquivo na área de stage por engano, pode removê-lo de lá, sem excluí-lo do diretório, com o comando git rm --cached <file>, como mostra a resposta do comando git status.

É importante resaltar que até o momento, nenhum arquivo está sendo monitorado pelo Git. O arquivo greet.py está pronto para ser "fotografado" e, a partir daí, ser monitorado. Para fotografar as mudanças que estão na área de stage deve-se executar o comando da lista de comandos 7.

Quando se executa o comando git commit sem o parâmetro -m 'comentário' o Git abre um editor de texto para que um comentário sobre a fotografia seja escrito. O Git não permite commits sem comentários. Então, foi usado aqui o parametro -m para ficar mais resumido e visível através das listas de comandos.

Se você quiser ver a fotografia tirada do sistema pode usar o comando git show e terá um resultado parecido com o da lista de comandos 8. Vamos entender essa fotografia.

Com o que foi mostrado neste capítulo, já dá para usar o Git para desenvolver seus programas. Nossos programas e outros documentos raramente são criados de uma vez. Começamos com uma versão simples e vamos incrementando versão após versão até finalizarmos o que precisamos fazer. Então, ao invés de fazer cópias dos nossos arquivos, podemos simplesmente alterar o arquivo sem medo. Por exemplo, digamos que fizemos uma alteração no arquivo greet.py e o programa parou de funcionar. Suponhamos que a alteração foi tão complicada que seria melhor descartar todas as alterações feitas e começar tudo de novo. Se ainda não executamos o comando git add greet.py, podemos descartar as alterações antes delas entrarem na área de stage. Basta executar o comando git checkout -- greet.py. Tudo voltará como estava no início.

Mas, se você tinha achado que a alteração seria uma boa idéia ou simplesmente executou o comando git add . sem querer, nenhum motivo para desespero. Basta usar o comando git reset -- greet.py. O Comando git add . adiciona na área de stage todas as alterações feitas no repositório. Se você usar o comando git reset todas as adições para a área de stage serão removidas para a lista de não monitorados. Daí você pode adicionar em stage somente os arquivos que você deseja na próxima fotografia.

Em resumo, você já pode usar o Git de maneira eficiente para implementar seus programas ou escrever seus documentos. Nos próximos capítulos você vai conhecer mais alguns comandos do Git que vão lhe ajudar a desenvolver seus trabalhos de forma mais eficiente e segura. Recomendo que você aprenda a usar um repositório remoto, de preferência na nuvem, em uma plataforma como o GitHub. Entretanto, se você já sabe como fazer isso, ou não tem interesse em usar um repositório remoto, você pode pular o capítulo seguinte e ir direto para o capítulo 4.

Agora que o repositório está criado, é necessário fazer um cópia local dele para poder alterá-lo. O link para fazer essa cópia pode ser encontrado clicando-se no botão "Clone" do repositório.

Depois de copiado o link, usasse o comando git clone <link> para fazer o download do repositório no computador local, como mostra a lista de comandos 9.

Agora, já é possível acessar o diretório criado e verificar que já existe fotografia (commit) do repositório. Esta foto foi "tirada" quando inserimos o arquivo "README.md", marcando a opção "Add a README file" ao criar o repositório no GitHub.

Para continuar, crie (ou copie) o arquivo greet.py de forma que ele tenha o conteúdo mostrado na listagem 11.

O comando git status agora traz uma informação a mais, como mostra a listagem 12. Agora aparece a linha Your branch is up to date with 'origin/main'. informando que a cópia local do repositório está atualizada com o repositório remoto hospedado no GitHub.

Vamos adicionar o arquivo greet.py na área de stage, como na listagem 13.

O próximo passo é fotografar as alteração da área de stage, como na listagem 14.

Note que os comandos e suas respectivas respostas neste capítulo estão muito parecidos com os do capítulo anterior. Por isso, algumas informações contidas lá não estão sendo repetidas aqui.

Para atualizar o repositório remoto usa-se o comando git push, como mostra a listagem 15.

Ao acessar o repositório no GitHub, pode-se ver as alterações atualizadas, como mostra a figura 7.

Alterações também podem ser feitas diretamente no site do GitHub. Por exemplo, para alterar o arquivo README.md, basta clicar no lápis da figura 7. Vamos mudar o título de # greetings para # Hello Git, como na figure 8, e depois clicar em Commit changes para fotografar esta alteração.

Para verificar se o repositório remoto foi alterado, usa-se o comando git fetch, como na listagem 16.

O comando git status da listagem 17 mostra que nossa cópia local está desatualizada por 1 fotografia (1 commit), e pode ser atualizada pelo comando git pull.

Então, podemos executar o comando git pull, como na listagem 18.

Agora o arquivo local está igual ao arquivo remoto, como pode ser visto na listagem 19.

Dentre algumas vantagens de se ter um repositório na nuvem, podemos citar algumas.

Você não precisa necessariamente usar a plataforma GitHub. Existem outras plataformas que também possuem tipos de contas sem custo para o usuário, como por exemplo, Bitbucket e GitLab, para citar algumas.

A listagem 28 mostra como listar as fotografias do sistema com o comando git log. A opção --oneline foi usada aqui para que as fotografias sejam vistas de um forma mais compacta. Mas você deve testar sem essa opção também.

A palavra HEAD indica o estado atual do repositório, seja ele local ou remoto. As fotografias do repositório são apresentadas em ordem cronológica reversa. Ou seja, a última fotografia registrada é a primeira a ser apresentada pelo comando git log. No início de cada linha vemos uma parte do hash de cada fotografia. Em geral, essa parte do hash é suficiente para visualizar ou acessar uma fotografia. Por exemplo, é possível ver uma fotografia mais antiga (ou mais recente) com o comando git show <hash>, onde normalmente, os quatro primeiros caracteres da parte do hash que aparece na listagem 28 é suficiente para identificá-la.

Na listagem 29 o comando git show mostra a fotografia anterior usando apenas a parte de seu hash listada na listagem 28. Note que o resultado da listagem 29 é identico ao da listagem 24. Ao seguir esses passos, lembre-se de substituir o hash 'e0fe2b3' pelo hash que aparece na sua lista de logs. Certamente terá um valor diferente.

A listagem 30 mostra a primeira fotografia do arquivo greet.py no repositório.

O comando git show <hash> é muito útil para verificarmos se uma determinada fotografia contém as alteração que precisamos. Despois de confirmarmos nossas suspeitas, podemos voltar o repositório para o estado que desejarmos.

O comando git checkout permite colocar o repositório em um estado gravado em alguma fotografia. A listagem 31 mostra como fazer o repositório voltar para o estado em que a função main do programa greet foi criada. Algumas linhas do resultado foram substituídas por "…​". Então, mais informações aparecerão quando você digitar esse comando. Ao seguir esses passos, lembre-se de substituir o hash 'e0fe2b3' pelo hash que aparece na sua lista de logs. Certamente terá um valor diferente.

Veja na listagem 32 que o programa greet.py voltou ao seu estado anterior.

Ao listar as fotografias do repositório, como mostra a figura 33, o comando git log não mostra mais o brach main, nem a fotografia da última alteração feita. Além disso, HEAD agora está na fotografia e0fe2b3.

Você pode estar se perguntando "Git é então um complexo ctrl+z?". Claro que não! A fotografia mais recente continua sendo monitorada e pode ser visualizada com a opção --all no comando git log, como mostra a figura 34.

Na verdade, o Git quase sempre adiciona informação ao repositório. Mesmo sendo possível remover informações de um repositório, isso é raramente recomendado. A figura 35 mostra como colocar o sistema no estado da fotografia mais recente.

Qualquer alteração nos arquivos monitorados pelo repositório deve ser feita enquanto o estado do repositório (HEAD) está apontando para um ramo (branch). Fotografias de alterações feitas fora de ramos não aparecem na resposta do comando git log, nem com a opção --all`.`

Para facilitar o acesso das fotografias pode-se etiquetá-las. O tipo de etiqueta mais comum é mostrado na figura 36, que usa o comando git tag com a opção -a. Esta opção permite usar a opção -m para inserir um comentário na etiqueta.

O comando git tag coloca a etiqueta na fotografia atual do sistema, mas é possível etiquetar outras fotografias através de seu hash, como mostra a figura 37.

A figura 9 mostra coma acessar uma fotografia antiga através de sua etiqueta

O comando git tag pode ser usado para listar as etiqueta, como mostra a figura 40.

Listagens mais complexas, com caracteres coringa por exemplo, podem ser feitas com esse comando, mas não serão exploradas aqui.

Quando se executa o comando git show com uma etiqueta, ele mostra também os dados da etiqueta, como pode ser visto na figura 41. A informação de quem fez a etiqueta (tagger) e de quando a etiqueta foi criada só é gravada se a opção `-a for usada na criação dela.

É importante notar que HEAD não aponta para nenhum branch. No caso, não aponta para main, que é o único branch do repositório. Para continuar o tutorial execute o comando da figura [fig:29], para que HEAD aponte para main.

Como ilustração, faremos uma versão brasileira para o nosso programa. Como eu supostamente ainda não sei se isso será fácil ou difícil de terminar, farei um branch como mostra a figura 44. Agora a fotografia mais recente tem dois ramos (na cor verde), main e pt-br.

Para fazer um alteração no ramo pt-br, deve-se mudar HEAD para esse ramo, como apresentado na figura 1. Agora HEAD aponta para pt-br.

Quando só existia o ramo main, cada comando commit movia o ramo main para a fotografia mais recente. Agora que HEAD aponta para pt-br, o comando commit vai mover o ramo pt-br para as novas fotografias, deixando o ramo main na fotografia atual. Assim, fica claro para todos os envolvidos no projeto que o ramo main contém uma versão estável do sistema.

Como ilustração será feita a alteração proposta na figura 45.

A resposta do comando git status da figura 46 já é conhecida. A única diferença do que já foi visto é a primeira linha que mostra que ramo atual é o pt-br (On branch pt-br).

O status após adicionar a alteração na área de stage mostrado na figura 47 também não é muito diferente do que já foi visto.

O resultado dos comandos git commit e git show apresentados na figura 49 também não apresentam muita novidade.

Note que o ramo main não tem nada de especial. Usar outro nome para um ramo não muda nada no processo de fotografar as versões do sistema.

Para mostrar como colocar uma alteração no ramo estável do sistema, vamos fazer a alteração proposta na figura 51. Estamos considerando o ramo estável deste repositório o ramo main, mas poderia ser qualquer outro nome.

Depois de colocar a nova alteração na área de stage (git add greet.py) e executar o comando git commit podemos ver a nova fotografia listada na figura 53.

A figura 54 mostra como ficou a fotografia mais recente do repositório. Também mostra como executar o programa na versão mais recente, caso ache interessante.

Agora que a alteração já foi finalizada, é hora de mesclar a atualização no ramo principal. A figura 55 apresenta um procedimento que pode ser executado com essa finalidade. Primeiro, temos que fazer HEAD apontar para o ramo principal com o comando git checkout main. Depois, usamos o comando git merge pt-br para mesclar o ramo pt-br com o ramo atual.

A figura 56 mostra a lista de fotografias depois da mesclagem de ramos.

Na segunda linha da reposta do comando git merge pt-br na figura 55 está escrito Fast-forward. Isso significa que nenhuma alteração foi feita no ramo main enquanto o ramo pt-br estava sendo alterado. Assim, não houve nenhum conflito para juntar as versões porque a versão mais recente de pt-br era como uma versão futura de main. A seguir, veremos um situação que isso não é resolvido tão facilmente.

Agora faremos uma versão do sistema em alemão. Para manter uma boa prática de Git vamos criar um novo ramo, como mostra a figura 57.

Para trabalhar no novo ramo, deve-se usar o comando git checkout. O comando git log mostra o ramo para o qual HEAD aponta.

Depois de fazer a alteração sugerida na figura 58, execute o comando git commit para deixar gravada as alterações no repositório.

A fotografia do último commit está na figura 60.

A figura 61 mostra que o sistema possui seis fotografias até o momento.

Na condição atual, no exemplo co capítulo anterior, o ramo foi mesclado com o ramo estável. Mas para exemplificar um conflito, não vamos mesclá-lo agora. Um motivo para não mesclar é não ter feito todos os testes no seu ramo. Ou o ramo ainda não está terminado. Vamos supor me nossa situações hipotética que não temos certeza que a resposta correta em alemão é hallo. Por isso, vamos adiar a mesclagem com o ramo principal.

Normalmente, conflitos de mesclagem não são criados intencionalemente. Mas para ilustrar a resolução de conflitos que inevitavelmente acontecerão, vamos fazer uma versão em italiano do nosso sistema para forçar um conflito. Para isso, vamos começar criando um novo ramo a partir de main. Após fotografarmos a alteração do sistema com a versão italiana, teremos dois ramos que nasceram a partir de main. Um deles é facilmente mesclável. O outro, nem tanto.

Uma forma de se criar um ramo a partir de main é estando com HEAD apontando para main. Em seguida, usa-se o comando git branch para criar um novo branch, como na figura 62.

Implemente a alteração sugerida na figura 63.

Adicione as alterações na área de stage e execute o comando git commit para fazer a nova fotografia.

Após adicionar as alterações na área de stage e executar o comando git commit a fotografia mais atual deverá estar parecida com a da figura 64.

A opção --graph do comando git log lista as fotografias do repositório em forma de grafo, como na figura 65.

Note que acima do ramo main as linhas estão vermelhas, indicando um possível conflito. Observe que o ramo de (alemão), que é mais antigo que o ramo it (italiano), se mostra como um ramo que está saindo de um galho.

O último ramo criado foi o ramo it, mas aqui vasmos mesclá-lo ao ramo principal antes do ramo mais antigo, que é o ramo de. A figura 66 mostra uma forma de como isso pode ser feito. Ocorreu uma mesclagem do tipo fast-forward sem nenhum problema.

Na figura 67 podemos ver que o grafo não foi alterado, mas agora HEAD e main estão na fotografia mais recente.

Agora, veja figura 68 o que ocorre quando tentamos mesclar o ramo alemão com o ramo princial.

Conforme a figura 69, a ferramenta vimdiff pode ser selecionada como na figura 70.