Histórico e alterações

Introdução

Nos laboratórios anteriores, você aprendeu a inicializar uma “Máquina do Tempo” (repositório Git) e salvar seu primeiro snapshot. Mas um projeto não é estático: ele evolui. Você corrige bugs, adiciona recursos e atualiza a documentação.

O Git é excelente para acompanhar essa evolução. Ele permite que você:

Inspecione as alterações: veja exatamente quais linhas foram alteradas antes de salvá-las.
Consulte o histórico: reveja cada snapshot que já foi salvo para saber quem fez o quê e quando.

Esse é o verdadeiro valor do controle de versão: não apenas manter backups, mas preservar um histórico estruturado de como um projeto mudou ao longo do tempo.

Neste laboratório, você modificará um arquivo, inspecionará as diferenças exatas com git diff, salvará um novo snapshot e, em seguida, consultará o histórico do projeto com git log. Esse é o ciclo básico de revisão usado constantemente nos fluxos de trabalho reais com Git.

Modificar um arquivo do projeto

Começaremos com um repositório que já tem um commit (o “Initial commit”). Vamos simular a realização de uma tarefa nesse projeto.

Navegue até o diretório do projeto:

cd /home/labex/project

Confira o conteúdo atual de readme.txt:

cat readme.txt

Você deverá ver: Hello World

Modifique o arquivo adicionando uma nova linha ao final. Vamos incluir uma descrição simples:

echo "Git is a version control system" >> readme.txt

Verifique se o arquivo foi alterado:

cat readme.txt

Saída:

Hello World
Git is a version control system

O Git detectou que readme.txt está diferente da versão armazenada no último snapshot. O arquivo agora é considerado Modified.

Inspecionar alterações com Git Diff

Antes de salvar seu trabalho, é uma boa prática revisar exatamente o que foi alterado. É como revisar um texto antes de entregá-lo.

O Git fornece o comando diff para essa finalidade. Ele compara o arquivo no diretório de trabalho com o arquivo do último commit (snapshot).

Assim, git diff compara dois estados: o que está salvo no histórico e o que existe atualmente na sua árvore de trabalho. Esse é um dos principais recursos para revisar o trabalho antes de registrá-lo permanentemente.

Execute git diff para ver as alterações:

git diff

Analise a saída:

diff --git a/readme.txt b/readme.txt
index ...
--- a/readme.txt
+++ b/readme.txt
@@ -1 +1,2 @@
 Hello World
+Git is a version control system

--- a/readme.txt: a versão original (antiga).
+++ b/readme.txt: a versão atual (nova).
+Git is...: o sinal de mais (+) indica uma linha adicionada recentemente. (O sinal de menos - indicaria uma linha removida).

Saber ler a saída de diff é uma habilidade fundamental do Git, pois ela mostra as alterações no nível das linhas. Muitos fluxos de trabalho posteriores, como revisão de código, aplicação de patches e pull requests, usam a mesma ideia.

Esta etapa confirma que suas alterações são exatamente as que você pretendia fazer.

Salvar alterações usando Git Commit

Agora que verificamos as alterações, vamos salvar um novo snapshot. Lembre-se do processo em duas etapas: Stage (colocar na área de carregamento) e Commit (tirar o snapshot).

Confira primeiro o status:

git status

Você verá readme.txt em vermelho, na seção “Changes not staged for commit”.

Faça o Stage do arquivo:

git add readme.txt

Confira o status novamente:

git status

Agora readme.txt aparecerá em verde, na seção “Changes to be committed”.

Este é outro exemplo da separação do Git entre conteúdo modificado e conteúdo em stage. Uma alteração pode existir no seu arquivo, mas, até que você faça o stage dela, não fará parte do próximo commit em potencial.

Faça o Commit do snapshot com uma mensagem clara:

git commit -m "Add description about Git"

-m: permite escrever a mensagem do commit imediatamente.
A mensagem deve identificar o que você alterou.

Agora você salvou a segunda versão do histórico do seu projeto!

Consultar o histórico do projeto

Agora seu repositório tem dois commits. Para ver a linha do tempo do projeto, use o comando git log. Esse é o seu “Livro de História”.

Exiba o log completo:

git log

Analise a saída:

commit 8d3a1b2... (SHA Hash)
Author: Your Name <you@example.com>
Date:   Mon Oct 10 10:00:00 2023 +0000

    Add description about Git

commit 4f2b3c4... (SHA Hash)
Author: Your Name <you@example.com>
Date:   Mon Oct 10 09:00:00 2023 +0000

    Initial commit

SHA Hash: a longa sequência de identificação (por exemplo, 8d3a...). Ela é uma impressão digital exclusiva desse snapshot específico.
HEAD: (se estiver visível) um ponteiro que mostra onde você está no momento.
Ordem: o commit mais recente sempre aparece no topo.

Esses hashes são fundamentais para a forma como o Git identifica o histórico. Em vez de nomear os commits com números sequenciais, o Git usa identificadores baseados no conteúdo, para que cada snapshot tenha uma referência exclusiva.

(Pressione q para sair da visualização do log, se necessário).

Consultar o histórico resumido

À medida que você trabalha em um projeto durante meses, o git log completo pode ficar longo e detalhado demais. Às vezes, você quer apenas uma lista rápida e resumida.

O Git oferece a opção --oneline para essa finalidade.

Execute o comando de log resumido:

git log --oneline

Confira a saída:

8d3a1b2 Add description about Git
4f2b3c4 Initial commit

Essa visualização mostra apenas o Short Hash e a Commit Message, uma por linha. Ela é ideal para verificar rapidamente o que aconteceu recentemente.

Desafio:

Tente modificar readme.txt mais uma vez (adicione outra linha), faça o commit e confira git log --oneline novamente. Você deverá ver três entradas!

Resumo

Neste laboratório, você aprendeu a gerenciar o ciclo de vida das alterações em um projeto:

Modificar: você alterou um arquivo.
Inspecionar: usou git diff para verificar essas alterações.
Fazer commit: salvou um snapshot permanente usando git add e git commit.
Revisar: explorou a linha do tempo usando git log e git log --oneline.

Esses quatro comandos são o coração do uso diário do Git. Domine-os para dominar os conceitos básicos do controle de versão.