O básico que funciona
Fazer um commit no git é uma das operações mais simples que existem, mas também a que todo mundo bota a perder por pressa ou por não prestar atenção. O processo tem três etapas obrigatórias: preparar as mudanças, adicioná-las à área de staging e confirmar o commit.
como fazer um commit no git
A linha de comando que você vai usar na maioria das vezes é uma sequência de três comandos. Primeiro, verifique o que mudou com git status. Esse comando mostra os arquivos modificados, os que estão prontos para serem adicionados e os que ainda não são trackeados pelo repositório. Não pule essa etapa. Eu vi muita gente pular e acabar fazendo commit do arquivo errado, o que gera dor de cabeça na hora de reverter. Depois, adicione os arquivos que deseja commitar. Você pode adicionar um arquivo específico com git add nome-do-arquivo ou todos os arquivos modificados de uma vez com git add -A. A diferença entre eles importa. O comando com -A inclui remoções e modificações. Se você usar apenas git add ., ele não inclui novos arquivos criados em subdiretórios. Isso é algo que armadores de problema acontecem quando alguém usa o ponto e espera que tudo seja capturado.
Por fim, confirma com git commit -m "mensagem descritiva". A mensagem é importante porque é o registro que seu time vai ler daqui a três meses quando precisar entender por que determinada mudança foi feita. Escreva algo claro. Evite mensagens como "fix" ou "update". Isso não ajuda ninguém. Um commit cria um snapshot do estado dos seus arquivos naquele momento exato. Cada commit recebe um hash único, que é basicamente uma assinatura digital baseada no conteúdo de todos os arquivos incluidos nele. Se você modificar um único caractere, o hash muda completamente. Isso é intencional e é o que garante a integridade do histórico.
O problema que ninguém conta
Existem situações em que o commit simples falha, e a maioria dos tutoriais não menciona isso. Eu tive um caso recente em que fiz um commit de um arquivo de configuração que continha uma senha. Pensei que estava tudo certo porque a senha não era visível no código fonte, mas o arquivo inteiro foi versionado. O commit foi feito, o push foi feito, e só percebi o erro uns dois dias depois quando revisei o histórico. A solução nesse caso não é fácil. Você precisa limpar o histórico usando git filter-branch ou git-filter-repo, que são ferramentas diferentes. O filter-branch faz parte do próprio Git, mas é lento e pode corromper refs se você não tomar cuidado. O git-filter-repo é mais rápido e mais seguro, mas precisa ser instalado separadamente porque não vem incluído no pacote padrão. Para o meu caso específico, eu usei o seguinte comando:
👉 Clique no botão abaixo para saber mais sobre o assunto!
git filter-repo --invert-paths --path senha.conf Isso removeu o arquivo de todo o histórico, substituindo os commits antigos por novos com hashes diferentes. O problema é que essa operação rewriting history vai quebrar o histórico de qualquer pessoa que já tenha puxado aquele repositório. Se você estiver trabalhando em um projeto colaborativo e precisar fazer isso, avise a equipe inteira antes. Senão, você vai receber uma enxurrada de mensagens de conflito de merge.
Dicas que realmente importam
O git diff é uma ferramenta subutilizada. Antes de fazer commit, rode git diff --staged para ver exatamente o que está na área de staging. Se alguma linha indesejada apareceu aí, tire ela antes de confirmar. Uma vez eu cometi uma função inteira de debug que deixava logs sensíveis no console por acidente. Foi vergonhoso corrigir depois. Para commits pequenos e frequentes, considere usar git commit --amend. Ele permite ajustar o último commit sem criar um novo na pilha. Isso é útil quando você percebe um erro de digitação na mensagem ou esqueceu de adicionar um arquivo. O amendo reescreve o commit anterior. Novamente, isso é rewriting history, então não faça amend em commits que já foram compartilhados com outras pessoas, a menos que esteja sozinho no repositório ou tenha conversado com a equipe.
Outro ponto que muita gente ignora: use git stash se você precisa fazer commit de uma parte do trabalho mas ainda não terminou outra. O stash salva suas mudanças temporariamente na pilha e limpa o working directory, permitindo que você faça commit do que já está pronto sem comprometer o que ainda está em desenvolvimento. Depois é só dar git stash pop para recuperar. Se você trabalha com branches, saiba que um commit pertence ao branch onde foi criado. Fazer commit na branch main ou master direto é possível, mas não é recomendado em ambientes de produção. O fluxo padrão é criar uma feature branch, fazer os commits nela, e depois merger de volta para a branch principal via pull request ou merge request. Isso dá visibilidade ao código antes de entrar no ramo principal.
Quando o Git não resolve
Commit no Git tem limitações. O sistema é otimizado para rastreamento de texto, não para binários grandes. Se seu repositório contém arquivos como vídeos, modelos de machine learning ou datasets pesados, o Git vai ficar lento e o histórico vai inchar rapidamente. Nesse cenário, a solução é usar o Git LFS (Large File Storage), que substitui os arquivos grandes por ponteiros leves no repositório e guarda os arquivos reais em um servidor separado. Também é importante notar que Git não oferece controle de acesso granular por arquivo ou pasta dentro do repositório. Se você precisa de permissões diferentes para diferentes partes do código, o Git sozinho não resolve. Nesse caso, depende de soluções externas como restrições no servidor de hosting (GitHub, GitLab, Bitbucket) ou ferramentas como gitolite. Isso não é um defeito do Git, é uma escolha de design. O Git foca em versionamento distribuído e não em gestão de permissões.
Aprender a fazer commit no git é o primeiro passo, mas entender quando e como usar cada variação desses comandos é o que separa quem opera no básico de quem realmente domina o fluxo de trabalho. O resto vem com prática e com a experiência de errar e consertar.
