O Git costuma assustar por um motivo bem específico: você salva um arquivo, mas ele ainda não está no histórico; roda um comando e aparece uma área chamada staging; faz um commit e nada parece mudar na pasta. A ferramenta não está escondendo seus arquivos. Ela está separando etapas que, no começo, parecem uma coisa só.
Quando essa separação fica clara, o trabalho muda de figura. Você consegue olhar o que alterou, escolher apenas alguns arquivos para o próximo registro e voltar atrás sem jogar fora tudo. Este é o fluxo básico para ganhar confiança: ver o estado, revisar a diferença, preparar o que faz sentido, registrar uma mudança pequena e só depois desfazer algo com intenção.
As três áreas que explicam quase tudo
O Git trabalha com três lugares diferentes. A working tree, ou árvore de trabalho, é a pasta que você está editando. Quando muda um arquivo, a alteração aparece ali, mas ainda não foi escolhida para entrar no próximo commit.
O staging, também chamado de index, é uma seleção intermediária. Ele funciona como uma bandeja: você coloca nela os arquivos ou trechos que quer registrar agora. Isso permite deixar uma mudança inacabada fora do próximo commit, em vez de misturar tudo só porque está na mesma pasta.
O terceiro lugar é o histórico de commits. Um commit é um registro identificado de uma versão do projeto. Ele não é um backup mágico de cada movimento, nem precisa representar o projeto inteiro em todos os momentos. Um bom commit explica uma mudança coerente, como “corrige validação do formulário” ou “adiciona tela inicial”.
Essa divisão também explica uma confusão comum: git add não publica nada e não envia arquivos para a internet. Ele apenas atualiza o staging. O comando git commit cria o registro local. Para enviar esse registro a um servidor remoto, você ainda usaria git push, em uma etapa separada.
Um fluxo seguro antes do primeiro commit
Comece por git status. O comando mostra em qual branch você está e quais arquivos foram modificados, adicionados ou removidos. Ele é o painel de controle do repositório. Antes de qualquer comando que altere o estado, vale olhar essa saída.
Depois use git diff para ler as alterações que ainda estão fora do staging. Não confie apenas no nome do arquivo. Uma mudança pequena pode ter entrado no lugar errado, carregado uma senha de teste ou apagado uma linha importante. A revisão é onde você descobre esse tipo de acidente.
Quando um arquivo estiver pronto para o próximo registro, adicione-o com git add caminho/do/arquivo. Para adicionar dois arquivos específicos, informe os dois caminhos. Evite começar com git add . enquanto ainda está aprendendo: o comando pode incluir arquivos temporários, chaves locais, builds e outros itens que você não queria registrar.
Agora rode git diff --staged. Esse detalhe é importante: git diff mostra o que ainda não foi preparado; git diff --staged mostra exatamente o conteúdo que o próximo commit receberá. Se o resultado estiver correto, registre a mudança:
git commit -m "corrige validação do formulário"Uma mensagem curta e específica ajuda mais do que “alterações” ou “update”. O histórico serve para você voltar a um contexto semanas depois, inclusive quando o autor do commit é você mesmo e a memória já foi embora.
Como separar mudanças que foram misturadas
Imagine que você corrigiu um botão e também começou a trocar as cores da aplicação no mesmo arquivo. O botão está pronto; as cores ainda não. O staging permite registrar apenas parte do trabalho, mas o comando mais simples, git add arquivo, adiciona o arquivo inteiro.
Para escolher trechos, use git add -p. O Git mostra cada bloco de diferença e pergunta o que fazer. Responda y para incluir o bloco, n para deixá-lo de fora e q para sair. As opções variam conforme o caso, mas a ideia é sempre a mesma: o commit deve conter uma mudança que você consiga explicar.
Depois de preparar uma parte, confira de novo com git diff --staged e compare com git diff. O primeiro mostra o que já está no próximo commit; o segundo mostra o que continua apenas na pasta. Essa dupla é mais útil do que decorar uma lista enorme de comandos.
Desfazer sem apagar o trabalho inteiro
Se você alterou um arquivo e quer descartar somente o que ainda não foi para o staging, use git restore caminho/do/arquivo. O comando recupera a versão que estava no último commit. Como ele remove a alteração local, não o use antes de revisar o arquivo. Se existir qualquer dúvida, copie o conteúdo para outro lugar ou faça um commit temporário antes.
Se o arquivo já está no staging, primeiro retire-o da seleção com git restore --staged caminho/do/arquivo. Isso não apaga a edição; apenas devolve o arquivo à working tree. Você poderá corrigir o conteúdo, revisar novamente e adicioná-lo depois.
Um commit recente também pode precisar de correção. Se você esqueceu um arquivo ou quer ajustar a mensagem antes de compartilhar o histórico, git commit --amend altera o último commit. Use com cuidado depois de um git push, porque reescrever um registro que outras pessoas já baixaram pode criar confusão.
Para desfazer uma mudança que já está no histórico compartilhado, a opção mais segura costuma ser git revert. Ele cria um novo commit que inverte o efeito de outro. Já git reset move o ponteiro do histórico e pode apagar referências dependendo do modo usado. Não trate os dois comandos como sinônimos. Em um repositório de estudo, leia a documentação e faça um teste; em um projeto de equipe, confirme a política do grupo antes de reescrever histórico.
Um exercício pequeno para perder o medo
Crie uma pasta de teste e inicialize um repositório com git init. Adicione um arquivo de texto, execute git status, prepare-o com git add e faça o primeiro commit. Em seguida, escreva uma segunda linha, veja o resultado de git diff e descarte essa alteração com git restore. Faça uma terceira edição, prepare-a e observe a diferença entre git diff e git diff --staged.
O objetivo não é memorizar comandos em uma tarde. É enxergar a sequência: a pasta muda, você revisa, escolhe o que será registrado e cria um ponto de retorno. Quando algo der errado, pare e rode git status antes de tentar consertar no impulso. Na maioria dos sustos iniciais, esse comando já mostra onde o trabalho está.
Fonte: Git SCM, Recording Changes to the Repository. Para o fluxo de repositório remoto, consulte também a documentação do GitHub Hello World.
