Git — Primeiro ciclo

Esse card é o coração do dia a dia: como sair de "fiz uma alteração no código" e chegar em "tirei uma foto e guardei na linha do tempo". Três comandos compõem esse ciclo: git status (o radar), git add (selecionar o que vai virar foto) e git commit -m (tirar a foto). Mas antes dos comandos, é preciso entender os três estágios que o git mantém por dentro — sem esse modelo na cabeça, os comandos parecem arbitrários.

Os três estágios do git

O git divide os arquivos em três áreas conceituais. Cada arquivo do seu projeto está em um (ou mais) desses estágios a qualquer momento:

1. Working tree (árvore de trabalho) — os arquivos como você os edita no disco. É onde você abre o VS Code e escreve código. Tudo o que você modifica primeiro passa por aqui.
2. Staging area (área de espera, ou stage, ou index) — uma "antessala" entre o working tree e o repositório. Você seleciona aqui o que quer que entre no próximo commit. Mudanças que ficam só no working tree NÃO entram no commit.
3. Repository (repositório, dentro da .git) — onde os commits ficam guardados pra sempre. Quando você commita, o conteúdo do stage vira uma foto definitiva aqui.

O fluxo é sempre nessa ordem: working tree → stage → repo. Você edita, depois adiciona ao stage, depois commita. Cada comando do ciclo movimenta arquivos de um estágio pro outro.

Por que existe o stage? Pra você poder ser seletivo. Imagina: você editou 5 arquivos, mas só 2 estão prontos pra commitar. Os outros 3 estão pela metade. Sem o stage, todo commit pegaria todos os arquivos modificados — você teria que commitar tudo ou nada. Com o stage, você adiciona só os 2 prontos, commita, e os outros 3 continuam no working tree pra você terminar.

git status — o comando-radar

O git status mostra em que estado cada arquivo está. É o comando que você roda o tempo todo — antes de adicionar, depois de adicionar, antes de commitar, depois de commitar. Ele te diz exatamente o que o git "vê".

git status

O output divide os arquivos em três grupos:

• Changes to be committed (em verde) — arquivos no stage, prontos pra entrar no próximo commit.
• Changes not staged for commit (em vermelho) — arquivos modificados no working tree, mas que ainda não foram adicionados ao stage.
• Untracked files (em vermelho) — arquivos novos que o git ainda não conhece. Não estão sendo versionados.

Quando o repositório está "limpo" (nenhum arquivo modificado, nada no stage), o git mostra nothing to commit, working tree clean. Esse é o estado-meta depois de cada commit.

git add — selecionando pro stage

O git add move um (ou vários) arquivos do working tree pro stage. É o comando da seleção.

git add caminho/do/arquivo.java
git add .
git add -p

Três variantes:

• git add <arquivo> — adiciona um arquivo específico. É o jeito seletivo, recomendado quando você quer controle total.
• git add . — adiciona todos os arquivos modificados e novos da pasta atual pra baixo. Mais rápido, mas perigoso: pode pegar arquivos sensíveis (.env, credenciais, builds gigantes) sem você ver. Só usar depois de um git status revisado.
• git add -p — modo "patch". O git pergunta arquivo por arquivo, pedaço por pedaço, se você quer adicionar. Útil quando um único arquivo tem mudanças que vão entrar em commits diferentes.

Detalhe importante: quando você adiciona um arquivo ao stage e depois edita ele de novo, a edição posterior fica só no working tree — não entra no stage automaticamente. O git status vai mostrar o mesmo arquivo nos dois lugares (verde + vermelho). Pra incluir a edição nova, roda git add de novo.

git commit -m — tirando a foto

O git commit pega tudo o que está no stage e cria uma foto (commit) na linha do tempo. Tudo o que estava no working tree mas não foi adicionado ao stage fica de fora.

git commit -m "Adiciona DepartamentoForm com 4 campos"

A flag -m ("message") permite passar a mensagem direto na linha de comando. Sem ela, o git abriria o editor padrão (Vim, ou o que você configurou no card de Setup) pra você digitar a mensagem.

O que acontece quando você commita:

1. O git pega o conteúdo atual do stage.
2. Junta com sua mensagem, seu nome, e-mail e data/hora.
3. Calcula o hash do conjunto.
4. Grava como novo commit na .git, apontando como pai pro último commit da branch atual.
5. O stage é "esvaziado" (na verdade, ele agora reflete o estado do último commit — que é exatamente o que acabou de virar foto).

Depois do commit, um novo git status mostra: o que estava só no working tree continua lá; mas o que estava no stage virou histórico — não aparece mais como pendente.

Anatomia de uma boa mensagem

A mensagem do commit é a parte que vai pro histórico — ela é lida por você daqui um ano, ou por colegas tentando entender o que mudou. Algumas regras práticas:

• Verbo no presente, no início. "Adiciona X", "Corrige Y", "Refatora Z". Não "Adicionei", não "Corrigindo". O git usa convenção de presente porque a mensagem descreve o que aquele commit faz ao ser aplicado, não o que você fez.
• Curta e descritiva. Máximo ~72 caracteres na primeira linha. Se precisa explicar mais, deixa em branco e escreve um corpo separado (não cabe no -m simples).
• Foca no "o quê" e "por quê", não no "como". "Corrige cálculo de imposto" é melhor que "Muda variável de int pra double". O como está no diff.
• Um commit = uma mudança lógica. Se você está descrevendo a mensagem com "e" no meio ("adiciona X e corrige Y"), provavelmente deveriam ser dois commits separados.

Exemplos bons: "Adiciona validação de e-mail no DepartamentoForm", "Corrige NPE no DepartamentoBean.toString", "Refatora ProdutoList pra usar setOnclick".

Exemplos ruins: "mudancas", "alteracoes", "trabalho de hoje", ".", "WIP".

O ciclo completo demonstrado

Juntando os três comandos, esse é o ciclo padrão de um commit:

git status
# vê: 3 arquivos modificados, 1 novo

git add src/Departamento.java src/DepartamentoForm.java
# adiciona 2 dos 3 modificados ao stage

git status
# confirma: 2 no stage (verde), 1 no working tree (vermelho), 1 untracked

git commit -m "Adiciona DepartamentoForm com 4 campos"
# tira a foto

git status
# resultado: 1 modificado no working tree, 1 untracked. Stage limpo.

Repare que rodamos git status três vezes — antes do add, depois do add, depois do commit. Cada passagem confirma o que está pra ser commitado e o que ainda fica de fora.

Erros comuns no começo

• Esquecer o git add antes do commit. Você edita o arquivo, roda git commit -m "..." direto, e o git diz "nothing to commit". Faz sentido: você não selecionou nada pro stage. Roda git add primeiro.
• Commitar arquivo errado com git add .. O add . pega tudo, inclusive um arquivo de senhas que você esqueceu. Solução: rodar git status antes, conferir a lista, e usar git add <arquivo> específico. Se já commitou, tem como desfazer (vem nos cards finais).
• Mensagens vazias ou genéricas. Daqui 6 meses você vai abrir o histórico e não vai entender o que cada "atualização" foi. Investe 10 segundos numa mensagem decente.
• Não rodar git status. O status é grátis e instantâneo. Roda sempre. Não tem problema rodar 20 vezes por sessão.