Git com agente: commit, branch e code review assistido

O agente já enxerga seu estado de git desde o primeiro turno: branch atual, arquivos modificados e commits recentes entram como um bloco próprio no fim do prompt de sistema. O que muda de configuração para configuração é o que ele faz sem perguntar.

E aí existe uma lista documentada de operações que o auto mode recusa por conta própria, sem você escrever regra nenhuma. Conhecer essa lista muda o que vale delegar.

No auto mode, um segundo modelo revisa as ações no lugar de você. Para git, ele já vem com uma lista de recusa que cobre o que costuma doer.

Descarte de trabalho não commitado. Seis comandos que o classificador presume que jogariam mudanças fora: git reset --hard, git checkout -- ., git restore ., git clean -fd, git stash drop e git stash clear.

Reescrita de histórico compartilhado. Force push é bloqueado. git commit --amend também, em dois casos: quando o commit no HEAD não foi criado nesta sessão, e quando ele já foi enviado ao remoto. A exceção é reescrever só a mensagem de um commit que o próprio agente criou na sessão, sem nada novo no stage.

Há um detalhe de confiança que vale conhecer. O classificador confia no seu diretório de trabalho e nos remotes que já estavam configurados quando a sessão abriu. Um remote adicionado ou repontado no meio da sessão, com git remote add ou git remote set-url, não herda essa confiança. É uma proteção contra o caso em que alguém convence o agente a apontar seu código para outro lugar.

Isso é padrão de comportamento, não regra de permissão. Para garantia que não depende do classificador, o caminho é uma regra de negação, tratada em permissões e auto mode:

{
  "permissions": {
    "deny": ["Bash(git push --force *)", "Bash(git reset --hard *)"],
    "ask": ["Bash(git push *)", "Bash(gh pr merge *)"]
  }
}

Vale lembrar que comandos git somente-leitura, como git status, git diff e git log, já rodam sem prompt em qualquer modo. Liberá-los na configuração é ruído.

Gerar mensagem de commit é a delegação de melhor retorno em git, porque o agente enxerga o diff inteiro e você não precisa reler o que acabou de escrever.

O que eu não delego é o recorte dos commits. Decidir o que entra em cada commit é decisão de história do projeto, e o agente tende a agrupar por arquivo em vez de por intenção. O padrão que funciona: você faz o git add do que forma uma unidade, e pede a mensagem para o que está no stage.

Duas coisas ajudam mais que qualquer prompt:

Convenção no CLAUDE.md. Formato de mensagem, idioma, prefixo de tipo, referência a issue. É o tipo de regra que precisa valer sempre, e por isso mora ali e não numa skill. A anatomia do arquivo cobre o resto.

Hook em vez de instrução, quando é garantia. "Rode os testes antes de commitar" no CLAUDE.md é pedido. Um hook PreToolUse que casa com Bash e sai com código 2 é bloqueio de verdade.

Aqui está o recurso que mais muda o fluxo de quem roda mais de uma tarefa por vez. Um worktree é um diretório de trabalho separado, com arquivos e branch próprios, compartilhando o histórico do mesmo repositório.

claude --worktree feature-auth

Isso cria o checkout em .claude/worktrees/feature-auth/, na branch nova worktree-feature-auth, e inicia a sessão lá dentro. Rodar o comando de novo com outro nome, em outro terminal, dá uma segunda sessão que não encosta nos arquivos da primeira. Omitindo o nome, o Claude Code gera um, do tipo bright-running-fox.

Três ajustes que valem no primeiro dia.

Ignore o diretório. Coloque .claude/worktrees/ no .gitignore, ou o conteúdo dos worktrees aparece como arquivo não rastreado no checkout principal.

Leve os arquivos que o git ignora. Um worktree é checkout limpo, então .env e afins não estão lá. Um arquivo .worktreeinclude na raiz do projeto, com sintaxe de .gitignore, resolve:

.env
.env.local
config/secrets.json

A regra é estrita e boa: só copia arquivo que casa com o padrão e é ignorado pelo git, então nada rastreado é duplicado.

Escolha de onde a branch nasce. Por padrão o worktree parte da branch padrão do remoto, o que dá árvore limpa. Com worktree.baseRef em "head", ele parte do seu HEAD local e carrega os commits ainda não enviados. Útil quando o trabalho isolado precisa continuar de onde você está.

Dá também para partir de um pull request, o que encurta muito a revisão de código de outra pessoa:

claude --worktree "#1234"

As aspas são necessárias para o shell não tratar o # como início de comentário.

O isolamento é aplicado, não sugerido

Dentro de um worktree, o Claude Code bloqueia quatro classes de chamada que escapariam para o checkout principal:

A última não dá para desligar, e é a que mais surpreende: um heredoc que o Claude Code não consegue traçar é recusado mesmo sem git nenhum na linha. A saída é reescrever em comandos separados, e a mensagem de erro diz isso.

O mesmo conjunto de verificações vale para todo subagente criado a partir da sessão isolada. E dá para dar worktree próprio a um subagente, com isolation: worktree no frontmatter dele, o que é o jeito de rodar refatoração mecânica em paralelo sem conflito.

O que o worktree compartilha

Três coisas atravessam a fronteira, e as três são convenientes:

• O diretório .git, então git commit funciona de dentro do worktree, inclusive com o sandbox ligado.
• Plugins de escopo de projeto, que não precisam ser reinstalados por worktree.
• Aprovações de permissão: um "sim, e não pergunte de novo" dado dentro do worktree é salvo no settings.local.json do checkout principal, vale em todos os worktrees, e sobrevive à remoção daquele.

Na saída de uma sessão interativa, o Claude Code checa se há trabalho no worktree. Limpo e sem nome, ele remove sozinho. Com nome, ou com mudanças e commits dentro, ele pergunta antes.

O /code-review local não exige instalar nada e não depende de plano. Ele revisa os commits da sua branch à frente do upstream mais o que está no diretório de trabalho:

/code-review                      # branch atual + não commitado
/code-review main...minha-feature # um intervalo de refs
/code-review 1234                 # um pull request
/code-review --fix                # aplica os achados
/code-review --comment            # posta como comentário inline no PR

Ele roda como subagente forkado em segundo plano, com janela de contexto própria, então a revisão não enche sua conversa. Os achados chegam quando termina, o que combina com o argumento de custo da medição em 48 mil turnos e com o critério de quando delegar.

O nível de esforço muda a natureza do resultado, e isso é documentado: em low e medium a revisão relata só o que tem mais confiança, com menos falso positivo; de high para cima ela amplia a cobertura e pode incluir coisas de que está menos certa. O nível fica lembrado entre sessões até você digitar outro.

Existe também o serviço gerenciado, que revisa pull requests no GitHub e posta comentários inline. Vale saber três coisas antes de pedir para o time: está em research preview, é de planos Team e Enterprise, e custa em média US$ 15 a 25 por revisão, cobrados em créditos de uso e por fora da franquia do plano. O gatilho escolhido multiplica isso: revisar a cada push custa por push.

Uma escolha de projeto que evita atrito: o check run sempre conclui como neutro, então a revisão nunca bloqueia merge por regra de proteção de branch. Se você quer travar merge, precisa ler a contagem por severidade da saída do check no seu próprio CI.

O serviço gerenciado lê dois arquivos do repositório, com pesos diferentes.

O CLAUDE.md entra como contexto de projeto, e violação nova dele vira achado de nit. Funciona nos dois sentidos: se o seu PR muda o código de um jeito que deixa uma afirmação do CLAUDE.md desatualizada, isso também é apontado.

O REVIEW.md, na raiz do repositório, é instrução exclusiva de revisão, entregue direto aos agentes que encontram, verificam e classificam os achados. É onde se resolve o problema real de revisão automatizada, que é volume:

# Instruções de revisão

## O que é Importante aqui

Reserve Importante para o que quebra comportamento, vaza dado ou
impede rollback. Estilo e nomenclatura são Nit, no máximo.

## Limite os nits

No máximo cinco Nits por revisão. Se achou mais, diga "mais N itens
semelhantes" no resumo.

## Não reporte

- O que o CI já cobre: lint, formatação, erro de tipo
- Arquivos gerados em `src/gen/` e qualquer `*.lock`

## Sempre confira

- Rota nova de API tem teste de integração
- Log não inclui e-mail, ID de usuário nem corpo de requisição

Duas regras dele merecem destaque porque resolvem irritações previsíveis. A barra de verificação exige evidência antes de um tipo de achado ser postado, algo como "afirmação sobre comportamento precisa de citação arquivo:linha, não inferência a partir do nome". E a convergência entre revisões evita a sétima rodada por estilo: "depois da primeira revisão, só reporte achados Importantes".

Uma assimetria que confunde: o /code-review local segue o seu CLAUDE.md, e não lê o REVIEW.md. O arquivo vale para o serviço gerenciado.

O arquivo não expande a sintaxe de importação @, então referenciar outro documento não funciona. As regras precisam estar ali dentro. E extensão tem custo: um REVIEW.md longo dilui as regras que importam.

Uma confusão que custa trabalho perdido. O Claude Code tira um retrato do arquivo antes de editar, e Esc duas vezes rebobina para um estado anterior. Isso é útil, é independente do git, e tem limites que precisam ficar claros:

E o caso que pega gente experiente: uma revisão de fundo que aplicou --fix escreveu fora dos checkpoints da sua sessão. /rewind não desfaz aquilo. Para reverter, é git.

A leitura prática é simples: checkpoint é rede de segurança da sessão, git é a rede de segurança do projeto. Commit antes de mandar o agente fazer algo amplo continua sendo o hábito que mais salva, e é o mesmo raciocínio do guia de Claude Code em produção. Para o fluxo até o servidor, o deploy de Next.js no GitHub e Hostinger fecha a cadeia.

O agente pode apagar meu trabalho não commitado?

No auto mode, os seis comandos que descartam mudanças (git reset --hard, git checkout -- ., git restore ., git clean -fd, git stash drop e git stash clear) são bloqueados pelo classificador por padrão. Isso é comportamento, não garantia contratual: para garantia, escreva uma regra de negação, que é avaliada antes de qualquer permissão.

Qual a diferença entre --worktree e criar a branch na mão?

O worktree dá um diretório separado, então duas sessões editam arquivos diferentes ao mesmo tempo sem conflito. Trocar de branch no mesmo diretório muda os arquivos debaixo de uma sessão que está trabalhando. O Claude Code ainda aplica quatro verificações que impedem comandos de escaparem do worktree para o checkout principal.

O /code-review local precisa do app do GitHub?

Não. Ele revisa o diff no terminal, sem instalar nada, e funciona em qualquer plano. O app do GitHub é para o serviço gerenciado, que comenta em pull requests, está em research preview e é restrito a planos Team e Enterprise.

Por que o /rewind não desfez as correções da revisão?

Porque a revisão roda em segundo plano e aplica as edições de --fix fora dos checkpoints da sua sessão. Quando ela roda em primeiro plano, editando durante o seu turno, o /rewind volta a alcançar. Para o caso de fundo, use git.

• Anthropic — Claude Code Docs: Code Review. Acesso em 21/08/2026.
• Anthropic — Claude Code Docs: Run parallel sessions with worktrees. Acesso em 21/08/2026.
• Anthropic — Claude Code Docs: Choose a permission mode. Acesso em 20/08/2026.
• Anthropic — Claude Code Docs: How Claude Code works. Acesso em 20/08/2026.
• Anthropic — Claude Code Docs: Configure permissions. Acesso em 20/08/2026.

Verificado em 21 de agosto de 2026.

Gatilho de reavaliação: revisar quando (a) a lista de comandos git bloqueados pelo classificador mudar, (b) o Code Review gerenciado sair de research preview ou chegar a outros planos, ou (c) o /code-review local passar a ler o REVIEW.md.