Dominando o Stage e Commit do Git: Suas Primeiras Alterações

Dominar os fundamentos do stage e commit do Git é o primeiro passo real para usar o Git com confiança. O staging permite que você escolha exatamente o que vai para o próximo snapshot, e o commit registra esse snapshot com uma mensagem que futuros leitores possam entender.

Se você tratar cada commit como uma pequena unidade de trabalho revisável, o Git se torna muito mais fácil de usar. Você pode inspecionar alterações, dividir edições não relacionadas e se recuperar de erros sem pânico.

Como Funciona a Área de Staging

O Git não faz commit automaticamente de todo arquivo que você edita. Ele separa seu trabalho em árvore de trabalho, área de staging e histórico de commits.

A árvore de trabalho é sua pasta de projeto. São os arquivos que você edita no seu editor.

A área de staging é a lista de verificação do Git para o próximo commit. Quando você executa git add, você ainda não está salvando o histórico. Você está selecionando alterações para o próximo commit.

O histórico do repositório é a sequência de commits já registrados.

Comece verificando o status:

git status

O Git mostrará arquivos não rastreados, arquivos modificados, alterações preparadas e sua branch atual. Este comando é seguro para executar a qualquer momento e deve se tornar um hábito.

Para preparar um arquivo novo ou modificado:

git add README.md

Para preparar todas as alterações no diretório atual:

git add .

Esse comando é conveniente, mas use com cuidado. Ele pode preparar arquivos não relacionados, configuração local ou saída gerada se seu .gitignore estiver incompleto.

Para uma revisão mais segura, inspecione o diff primeiro:

git diff

Depois, prepare apenas o que pertence junto:

git add src/app.js
git add README.md

Após preparar, verifique o que será commitado:

git diff --staged

Isso mostra exatamente o snapshot preparado. Se algo parecer errado, corrija antes de commitar.

Fazendo Seu Primeiro Commit

Depois que as alterações corretas estiverem preparadas, crie um commit:

git commit -m "Adicionar README do projeto"

A mensagem deve descrever a mudança, não a ação que você tomou. "Adicionar README do projeto" é mais útil do que "alterações" ou "atualizar arquivos".

Um bom commit geralmente tem um propósito claro. Por exemplo, suponha que você atualize um script de implantação e também corrija um erro de digitação em uma página de documentação. Essas são alterações separadas. Prepare e faça commit delas separadamente:

git add scripts/deploy.sh
git commit -m "Adicionar verificação de saúde na implantação"

git add docs/setup.md
git commit -m "Corrigir erro de digitação no guia de configuração"

Isso facilita a revisão. Também facilita o rollback se a alteração de implantação causar um problema, mas a correção da documentação estiver correta.

Se você executar git commit sem -m, o Git abre seu editor. Isso é útil quando você precisa de uma mensagem mais longa:

Adicionar verificação de saúde na implantação

Verificar o endpoint do serviço antes de marcar a implantação como concluída.
Isso ajuda a detectar falhas iniciais mais cedo no processo de lançamento.

A primeira linha deve ser curta e direta. O corpo pode explicar por que a mudança foi necessária ou mencionar trade-offs.

Para ver commits recentes:

git log --oneline -5

Isso fornece uma visão compacta do histórico mais recente.

Preparando Partes de um Arquivo

Às vezes, um arquivo contém várias edições não relacionadas. O Git pode preparar apenas parte de um arquivo com o modo patch:

git add -p src/config.js

O Git mostra cada bloco de alteração e pergunta o que fazer. Escolhas comuns são:

y: preparar este bloco.
n: não preparar este bloco.
s: dividir o bloco em partes menores, se possível.
q: sair do modo patch.

O patch staging é útil quando você está limpando antes de um commit. Por exemplo, você pode ter um arquivo onde adicionou uma nova configuração de timeout e também reformatou um comentário. Prepare a alteração de timeout para um commit, depois prepare a limpeza do comentário para outro.

Se você preparou algo por engano, desfaça o staging sem descartar seu trabalho:

git restore --staged src/config.js

Seu arquivo permanece modificado na árvore de trabalho. Ele é simplesmente removido da área de staging.

Se você quiser descartar alterações não preparadas em um arquivo, tenha cuidado:

git restore src/config.js

Esse comando descarta edições locais nesse arquivo. Execute git diff primeiro para saber o que está perdendo.

Para mais padrões de recuperação, veja como desfazer erros no Git.

Higiene de Commits para o Trabalho Diário

Commits pequenos e focados são mais fáceis de revisar, testar e reverter. Eles também tornam ferramentas como git bisect mais úteis quando você precisa encontrar onde um bug começou.

Use estes hábitos:

Execute git status antes de preparar.
Revise git diff antes de git add.
Revise git diff --staged antes de commitar.
Mantenha alterações não relacionadas em commits separados.
Escreva mensagens que expliquem o que mudou.
Evite commitar arquivos gerados, a menos que o projeto os espere.
Nunca comite segredos, chaves privadas ou valores de .env locais.

Um fluxo de trabalho prático pode ser assim:

git status
git diff
git add src/server.js
git diff --staged
git commit -m "Tratar resposta de verificação de saúde ausente"
git status

Essa sequência não é chamativa, mas pega a maioria dos erros de iniciante. Você sabe o que mudou, o que está preparado, o que foi commitado e o que resta.

Se sua equipe usa hooks de pré-commit ou formatação automatizada, um commit pode falhar até que você corrija a formatação ou os testes. Leia a mensagem de erro, execute o comando sugerido, prepare as alterações resultantes e faça commit novamente.

Quando Pedir Ajuda

Peça ajuda se você acidentalmente preparou ou cometeu segredos, se cometeu na branch errada, ou se não tem certeza se deve alterar, reverter, resetar ou fazer um novo commit. Essas escolhas têm efeitos diferentes, especialmente após um push.

Você também deve perguntar antes de reescrever commits que outras pessoas podem ter puxado. Uma simples limpeza local pode se transformar em um problema de equipe se alterar o histórico compartilhado.

Staging e committing são o loop central do Git. Revise suas alterações, prepare intencionalmente, faça commit em partes focadas e escreva mensagens que façam sentido daqui a um mês.