Vale a pena deixar o Claude Code commitar por você? O que decidir antes de soltar o agente no Git

Fala aí, beleza? Deixar o Claude Code escrever código é uma coisa, deixar ele mexer no histórico do teu repositório é outra bem diferente

Código ruim tu apaga e reescreve

Histórico ruim fica lá, com o teu nome junto

Aí vem a parte que muita gente não sabe: o Claude Code faz operações de Git (preparar as mudanças, escrever a mensagem de commit, criar branch, abrir PR) quando você pede explicitamente, não por conta própria. E no modo padrão ele ainda para e pede aprovação antes de cada mudança

Então a pergunta real nunca foi "ele vai commitar sozinho?"

A pergunta é: o que eu decido ANTES de autorizar? 🙂

Agente commitando por você x você commitando: o que muda em cada ponto

Os pontos de decisão são poucos, mas cada um muda bastante o resultado no repositório

Repara numa coisa: as duas últimas linhas não são equivalentes

O rewind e o Git resolvem problemas diferentes, e confundir os dois é onde as pessoas se queimam (volto nisso lá embaixo)

Pré-inscrição Formação Claude Code

Domine o Claude Code do básico ao avançado

Você vai aprender a criar sistemas completos com Claude Code, sem precisar ser programador. Inscreva-se para ter acesso a um desconto de lançamento e bônus especiais!

Quero minha vaga

Quando deixar o agente commitar compensa e quando é melhor você fechar o commit

Sessão exploratória, sem saber onde vai dar:

Aquele momento de "vamos ver se essa ideia presta"

Aqui deixar o agente commitar é MUITO conveniente, desde que o trabalho esteja isolado. Rodando claude --worktree <nome>, ele cria um diretório de trabalho separado (por padrão em .claude/worktrees/<nome>/, na raiz do repo) num branch novo chamado worktree-<nome>

Se você não passar nome, o Claude gera um (tipo bright-running-fox)

Decisão: libera o commit, mas dentro do worktree. Se a ideia morrer, morre com o branch dela junto

Várias sessões rodando em paralelo:

Duas ou três frentes ao mesmo tempo no mesmo projeto, e o clássico medo de uma pisar no arquivo da outra

O worktree resolve exatamente isso: é um diretório de trabalho separado, com arquivos e branch próprios, compartilhando o mesmo histórico e o mesmo remoto do checkout principal. Cada sessão no seu worktree, as edições de uma não tocam os arquivos da outra

Se o teu projeto depende de arquivo gitignorado (o .env da vida), dá pra listar ele no .worktreeinclude e ele é levado pra todo worktree novo

Decisão: uma sessão por worktree, commit liberado em cada uma, integração você resolve depois

Repositório compartilhado, onde o commit é parte da revisão:

Tem time onde a mensagem e o recorte do commit não são detalhe, são o material que o revisor lê pra entender a mudança

Nesse caso o agente pode preparar tudo, mas quem fecha é você

Decisão: deixa ele montar e propor, e antes de aceitar vale perguntar o porquê da mudança em vez de só apertar enter

Histórico auditado:

Aqui depende 100% da política do teu lugar

A atribuição automática (o trailer Co-Authored-By no commit e a marcação no corpo do PR) vem ligada por padrão. Em ambiente que exige deixar claro o que foi assistido por IA, isso é a favor. Em ambiente que trata isso como ruído no histórico, é contra

Decisão: você não precisa aceitar o padrão, isso é configurável (próxima seção)

Como definir os limites do agente no Git antes da primeira sessão

Bora pra parte prática

1. Escolha o modo de permissão. O default pede aprovação a cada mudança, o plan pesquisa e propõe sem editar nada até você aprovar, o acceptEdits auto aprova operações de arquivo (mas comandos Bash que não são de arquivo continuam pedindo permissão) e o bypassPermissions é só pra ambiente isolado tipo container ou VM. Dá pra passar como flag no início da sessão ou fixar como defaultMode no settings. O erro comum deste passo: achar que acceptEdits libera Git. Não libera, o comando de Bash continua parando pra você

2. Escreva as regras de Bash separando commit de push. É o pulo do gato do post: as regras permitem liberar e bloquear comandos de Git separadamente. A doc traz esse exemplo direto: Bash(git commit ) no allow e Bash(git push ) no deny. As regras usam glob, com em qualquer posição. O erro comum deste passo:* achar que a regra mais específica ganha. Não ganha! A ordem de avaliação é deny, depois ask, depois allow, e a primeira regra que casa decide, independente de ser mais ou menos específica

3. Sacou que git somente leitura não pede nada? As formas read-only do git são comandos embutidos e rodam sem prompt, e esse conjunto não é configurável. Se você quer confirmação em algum deles, tem que adicionar uma regra ask ou deny na mão. O erro comum deste passo: montar a política inteira supondo que "tudo de git passa por mim", quando a leitura já passa direto

4. Escolha o arquivo de settings certo. Configuração de usuário fica em ~/.claude/settings.json (no Windows, %USERPROFILE%\.claude), a do projeto em .claude/settings.json e a local em .claude/settings.local.json. O erro comum deste passo: colocar regra pessoal no arquivo do projeto e versionar isso pro time inteiro sem querer

5. Decida a atribuição. Ela mora no objeto attribution, com as chaves commit, pr e sessionUrl:

{
  "attribution": {
    "commit": "",
    "pr": "",
    "sessionUrl": false
  }
}

Deixando commit e pr como strings vazias e sessionUrl como false, você esconde toda a atribuição

E tome cuidado com uma pegadinha: a configuração includeCoAuthoredBy está depreciada e perde pro attribution. O attribution tem precedência, e o includeCoAuthoredBy só liga ou desliga o Co-Authored-By, sem deixar você customizar o texto

6. Isole o trabalho com worktree. Aquele claude --worktree <nome> (ou -w) da seção anterior:

claude --worktree feature-login

Isso cria o diretório em .claude/worktrees/feature-login/ e o branch worktree-feature-login

O erro comum deste passo: esquecer o que acontece na hora de limpar. Remover um worktree com git worktree remove apaga o diretório, o branch E todo o trabalho que estava dentro dele. Se o Git recusar porque está travado, aí é git worktree unlock antes

Já me imagino a cena de alguém rodando o remove achando que ia sobrar o branch, haha

Entrou coisa errada no repositório: como voltar atrás

Sintoma: a edição da sessão ficou ruim

Causa: o agente foi por um caminho que não era o que você queria e mexeu em vários arquivos no processo

Solução: abre o menu de rewind, com /rewind ou apertando Esc duas vezes com o campo de entrada vazio. O menu lista os prompts da sessão e te oferece restaurar código e conversa, só a conversa ou só o código

Sintoma: o rewind não desfez o que sumiu

Causa: o checkpointing só rastreia edições feitas pelas ferramentas de edição de arquivo. Mudança feita por comando de shell fica de fora, então os rm, mv e cp da vida não voltam pelo rewind

Tem mais um detalhe: na hora de restaurar código, caminhos que são symlink ou hard link são pulados. Esses arquivos ficam com o conteúdo atual e o Claude Code mostra um aviso

Solução: pra esses casos, quem salva é o Git mesmo. É o mesmo raciocínio de versionar o vault no Git antes de soltar o agente nas suas notas: rede de segurança primeiro, agente depois

Sintoma: quero contar com isso a longo prazo

Causa: confundir checkpoint com histórico. Os checkpoints são locais à sessão, separados do Git, e o Claude Code apaga eles junto com as sessões depois de 30 dias

Solução: a própria doc orienta continuar usando Git para histórico permanente. Rewind é desfazer da sessão, não é backup

Como prevenir: branch de trabalho ou worktree por sessão, e Bash(git push *) no deny

Assim, o pior cenário fica contido dentro de um branch que ninguém mais viu

Veredito: onde entregar o Git ao agente e onde segurar

Entregar preparo das mudanças, redação da mensagem e abertura de PR faz sentido, desde que duas coisas estejam de pé: permissões definidas e trabalho isolado

O que eu seguraria é o push e as operações que reescrevem histórico

Não porque o agente é ruim nisso, e sim porque essas são as operações onde o erro sai do teu computador e vira problema dos outros

E vale separar o comportamento por produto, sem misturar as coisas: no aplicativo desktop, em repositórios Git, cada sessão nova já ganha automaticamente uma cópia isolada do projeto via worktree, e as mudanças de uma sessão não afetam as outras até você commitar

Já o Claude Code na web não honra defaultMode em bypassPermissions nem dontAsk vindos dos arquivos de configuração. Ou seja: um settings versionado no repo não consegue iniciar sessão na nuvem em modo permissivo

Detalhe importante pra quem imagina que basta commitar um arquivo de config pra abrir tudo

Conclusão

Recapitulando as quatro decisões, uma frase cada:

Modo de permissão: default pra ver tudo passar, plan pra só propor, acceptEdits pra arquivos, e bypassPermissions só em ambiente isolado

Regras de Bash: commit liberado, push negado, lembrando que deny vem antes de ask, que vem antes de allow, e a primeira que casa decide

Atribuição: o objeto attribution com commit, pr e sessionUrl manda, e o includeCoAuthoredBy está depreciado

Isolamento: worktree por sessão, e o .worktreeinclude se você depende de arquivo gitignorado

O próximo passo é bem curto: abre o teu settings.json, escreve as duas regras de Bash (Bash(git commit ) no allow, Bash(git push ) no deny) e roda a próxima sessão em worktree

E pra quem quer bloqueio programático, não só declarativo: dá pra usar um hook PreToolUse, que consegue barrar um comando antes dele rodar. Saindo com código 2, a ação é bloqueada e o texto que você mandar pro stderr vira o motivo da negação. Com vários hooks, a precedência é deny, defer, ask, allow

Dá pra montar coisa bem insana com isso, mas aí já é assunto pro próximo post…