Como fazer commit apenas de parte de um arquivo no Git?
Resumidamente:
Use o comando:
git add -p
Explicando melhor
O comando git add -p (ou sua forma completa git add --patch) permite que você adicione ao stage apenas partes específicas de um arquivo, em vez de incluir tudo de uma vez.
Quando você executa:
git add -p
O Git percorre os arquivos modificados e, trecho a trecho (hunk), pergunta o que você deseja fazer com cada alteração:
❯ git add -p
diff --git a/ansible/file.yml b/ansible/file.yml
index 73f6b4d..899610f 100644
--- a/ansible/file.yml
+++ b/ansible/file.yml
@@ -52,7 +52,8 @@
loop:
- "service"
+ - "node_modules"
+ - "systemd_templates"
(1/1) Stage this hunk [y,n,q,a,d,e,?]?
Aqui entra a parte interativa:
- y → adiciona esse trecho ao stage
- n → ignora o trecho e deixa-o fora do stage
- q → sai do modo interativo
- a → adiciona todos os trechos restantes do arquivo
- d → ignora todos os trechos restantes
- e → permite editar manualmente o hunk antes de adicioná-lo
Essas opções tornam o processo muito mais flexível, permitindo que você construa commits bem organizados e focados.
Imagine, por exemplo, que você esteja ajustando um bug em um arquivo, mas ao mesmo tempo aproveitou para melhorar a formatação e adicionar comentários. Se você rodar apenas git add <arquivo>, tudo será incluído no commit de uma vez, misturando o bugfix com mudanças cosméticas.
Com git add -p, você pode escolher adicionar apenas a correção do bug e deixar a parte de formatação para um commit separado.
Lembre-se do índice (stage)
O stage (ou índice) é a área intermediária onde ficam armazenadas as alterações que você deseja incluir no próximo commit.
Quando você usa git add -p, está apenas decidindo quais mudanças vão para esse índice.
Nada é gravado no histórico ainda. Para consolidar, você precisa executar:
git commit -m "mensagem do commit"
Esse fluxo dá muito mais controle e ajuda a evitar aqueles commits gigantes que misturam várias coisas diferentes.
Por que isso é útil?
A forma mais comum de adicionar mudanças é com:
git add .
ou
git add <arquivo>
O risco é que você pode acabar adicionando modificações que nem lembrava que tinha feito, levando a commits desorganizados e difíceis de entender.
Quando isso acontece, o histórico do repositório perde clareza: fica complicado revisar mudanças, encontrar a origem de bugs ou até mesmo explicar o que cada commit realmente representa.
O git add -p resolve esse problema porque força uma etapa de reflexão.
Antes de mandar tudo para o stage, você olha cada pedaço de código e decide se ele deve ou não ir para o próximo commit.
Esse cuidado resulta em um histórico muito mais limpo, com commits:
- 📌 Pequenos e objetivos
- 📌 Sem alterações desnecessárias misturadas
- 📌 Que contam uma “história” clara do desenvolvimento
Exemplo prático
Imagine que você está desenvolvendo uma nova funcionalidade, mas no meio do caminho encontra um bug pequeno e o corrige rapidamente no mesmo arquivo.
Se você rodar apenas:
git add .
git commit -m "implementa feature X"
O bugfix vai acabar misturado com a feature.
Depois de semanas, quando alguém olhar esse commit, vai ser difícil entender que ali também havia uma correção.
Agora veja com git add -p:
- Você adiciona apenas o trecho do bugfix
git add -p
git commit -m "corrige bug Y em app.js"
- Depois adiciona a parte da nova funcionalidade
git add -p
git commit -m "implementa feature X"
Pronto, dois commits separados, cada um com um propósito bem definido.
Dica extra
Caso você tenha adicionado algo por engano ao stage, é fácil corrigir:
git reset <arquivo>
ou, se preferir a forma mais recente:
git restore --staged <arquivo>
Esses comandos removem o arquivo do índice, mas mantêm as alterações no diretório de trabalho. Assim você pode reorganizar seus commits sem perder nada.
Em resumo: usar git add -p pode parecer um passo a mais no início, mas traz vantagens a médio e longo prazo.
Seu histórico ficará mais organizado, os commits mais claros e a colaboração em equipe muito mais eficiente.