Fluxo de trabalho Git com Claude Code: automatize commits e PRs (2026)

O Claude Code consegue criar commits e PRs sozinho?

Sim — e é um recurso nativo, nada a instalar por fora. O Claude Code chama o git e o gh pela ferramenta Bash, então basta você dizer "commite as mudanças" e ele roda git status e git diff, lê o contexto e então redige a mensagem de commit. Diga "crie um pr" e ele roda gh pr create, gerando o título e o corpo a partir dos seus commits.

Requisitos mínimos: o repositório precisa estar inicializado com git init e você tem que estar dentro dele. Para abrir um PR você também precisa do gh CLI (GitHub CLI) logado. Se você não tiver, o Claude Code ainda commita numa boa — ele só não consegue abrir o PR pra você. Segundo a documentação de fluxos comuns da Anthropic (acessada em 09/08/2026), esses são fluxos oficialmente suportados, não gambiarras de terceiros.

Um aviso de confiança logo de cara: o Claude Code mexe no git pela camada de permissões da ferramenta Bash, então todo comando de escrita (commit, push) pede a sua aprovação, a menos que você já tenha concedido antes. Ele não faz push para um remoto sem você pedir — mas, como o final deste artigo mostra, ainda assim vale deixar isso explícito no CLAUDE.md para ter certeza.

Passo 1 - Configuração: git, o gh CLI e autenticação

Antes de entregar o git para o agente, confira três coisas. Abra um terminal (ou deixe o Claude Code rodar por você) e confirme:

git --version
gh --version
gh auth status

Se o gh avisar que não está instalado, instale o GitHub CLI e faça login uma vez:

# macOS
brew install gh
# Windows
winget install --id GitHub.cli
# After installing, log in (opens a browser to authenticate)
gh auth login

Escolha GitHub.com, depois HTTPS e então autentique no navegador. Feito isso, o gh guarda um token para abrir PRs em seu nome. Por fim, garanta que você está no repositório certo e em uma branch de trabalho:

git rev-parse --is-inside-work-tree # true if this really is a git repo
git branch --show-current

Dica: não trabalhe direto na main. Crie uma branch primeiro — você pode até pedir ao Claude Code: "crie uma branch feat/checkout e mude para ela". Uma branch limpa deixa o passo final do PR bem mais organizado.

Passo 2 - Escreva conventional commits corretos automaticamente

É aqui que o Claude Code brilha. Depois de terminar de codar, em vez de digitar a mensagem você mesma, dê a instrução:

commit the current changes using conventional commits

O Claude Code roda git status e git diff --staged (mais o diff não preparado), analisa o que você de fato mudou e então escreve uma mensagem no formato certo:

type(scope): short description in the present tense

- bullet detail if needed
- the reason for the change, not just a file list

Os valores de type mais comuns do Conventional Commits:

Dica para mensagens de mais qualidade: se você já preparou exatamente a parte que quer commitar (um git add deliberado), o Claude Code se atém ao diff preparado e chuta menos. Você também pode ser específica: "commite, o scope é 'checkout', foque no porquê da mudança em vez de listar arquivos". Quanto mais contexto você der sobre o porquê da mudança, mais útil a mensagem continua para quem for ler o histórico depois.

Sobre a linha "Co-Authored-By": por padrão, o Claude Code costuma anexar uma atribuição como Co-Authored-By: Claude <...> ao final do commit. Num repositório pessoal ou projeto paralelo, manter isso é inofensivo e transparente. Mas num repositório de empresa com convenções de commit rígidas (ou CI que valida o formato da mensagem com commitlint), você pode querer desativar. A solução mais simples é uma regra no CLAUDE.md: "não adicione uma linha Co-Authored-By nem qualquer assinatura de IA às mensagens de commit" — o Claude Code obedece. Isso é uma decisão de política do repositório, então combine com o seu time antes de ligar ou desligar para todo mundo. Se você quiser uma referência rápida dos comandos git que mais usa com o Claude Code, o cheat sheet do Claude Code tem uma tabela de consulta bem prática.

Passo 3 - Divida os commits por type/scope (divisão automática)

Na prática, você raramente muda só uma coisa. Uma única sessão de código pode adicionar um recurso, corrigir um bug e atualizar a documentação, tudo de uma vez. Enfie tudo isso num commit gigante e os revisores sofrem, e um revert arrasta junto mudanças sem relação. O Claude Code pode dividir para você:

these changes span several types. Split them into separate atomic
commits by type/scope, one type of change per commit

Ele agrupa o diff por tópico, prepara cada grupo (git add -p ou por arquivo) e então cria os commits um a um. Um diff misturado pode virar:

feat(payment): add VietQR payment flow
fix(payment): correct amount rounding
docs(payment): note the SEPAY_KEY environment variable

Por que vale a pena: cada commit atômico é uma unidade de revisão independente, o histórico fica claro de ler e, quando você precisar de git revert, remove só o que quebrou sem tocar no resto. Essa é uma técnica que quase nenhum guia menciona, mas é a grande diferença entre "deixar a IA commitar qualquer coisa" e "deixar a IA commitar como uma dev cuidadosa". Um porém: dê uma olhada nos commits que ele propõe antes de aprovar — de vez em quando os limites de scope que ele traça não batem com a estrutura dos seus módulos e, nesse caso, é só dizer "junte os dois primeiros commits".

Passo 4 - Procure segredos antes de commitar

Aqui está um risco real de deixar um agente commitar que quase nenhum guia menciona: o agente pode acidentalmente deixar escapar um .env, uma chave de API, um token ou uma string de conexão de banco de dados num commit — e, uma vez no histórico, limpar isso direito é um sufoco. Antes de commitar, peça para ele procurar:

before committing, scan the staged files for any secrets:
API keys, tokens, passwords, connection strings, or a stray .env file

A checklist de segurança que vale aplicar:

• Tenha um .gitignore que bloqueie .env, *.pem, *.key desde o começo do repositório.
• Peça ao Claude Code para inspecionar o diff preparado em busca de strings parecidas com chaves ou tokens antes de cada commit.
• Instale um hook de pre-commit que bloqueie na camada do git (por exemplo gitleaks ou git-secrets) para você não depender inteiramente do agente.
• Se você já commitou um segredo: trate aquele token como vazado — rotacione agora, não basta apagar o arquivo e commitar por cima.

Para automatizar essa parte por completo, você pode mover a varredura para um hook que roda antes do commit — veja como usar hooks no Claude Code para encaixar uma checagem automática. A regra de ouro: nunca confie totalmente a um agente o acesso de escrita ao seu histórico sem uma camada de bloqueio no nível do git.

Passo 5 - Abra um pull request automaticamente com gh

Com os commits limpos, abrir um PR é uma frase só:

create a pr

O Claude Code faz push da branch (se você deixar), roda gh pr create e redige o título e o corpo a partir dos commits da branch — incluindo um resumo das mudanças e uma checklist se o repositório tiver um template de PR. Você pode ser mais específica: "abra o PR contra a branch develop e detalhe os testes que eu rodei".

Uma dica bacana da documentação da Anthropic: um PR criado com gh pr create fica automaticamente vinculado à sessão do Claude Code que o produziu. Depois, quando você for revisar de novo, reabre exatamente aquele contexto de sessão com:

claude --from-pr 1234

Muito útil quando um revisor deixa comentários e você quer que o Claude Code continue trabalhando neles lembrando de todo o contexto original.

Se você precisar de operações mais profundas do GitHub nesse ponto — ler issues, comentar, gerenciar pedidos de revisão dentro da sessão — combine o GitHub MCP com o Claude Code em vez de depender só do gh. O MCP deixa o Claude Code "enxergar" todo o contexto do GitHub, não apenas rodar comandos de CLI.

Padronize com o CLAUDE.md e um slash command /commit

Instruções em linguagem simples são rápidas, mas se você tiver que repetir "conventional commits, não faça push, sem assinatura de IA" toda vez, transforme isso numa regra fixa. Coloque o bloco a seguir num arquivo CLAUDE.md na raiz do repositório — o Claude Code lê ele toda sessão:

## Git Rules
- Commit using Conventional Commits: type(scope): description (present tense).
- Types to use: feat, fix, docs, refactor, chore, test.
- Split a mixed diff into atomic commits by type/scope.
- Scan for secrets (API keys, tokens, .env) before every commit.
- Do NOT run git push on your own; push only when I explicitly ask.
- Do NOT add a Co-Authored-By line or any AI signature to commit messages.
- Scope names follow the repo's module/folder names.

Para entender como escrever bem esse arquivo, veja o guia de como escrever regras de git no CLAUDE.md. O próximo passo é embrulhar todo o processo num slash command personalizado, para o time inteiro rodar exatamente o mesmo fluxo com um comando só. Crie o arquivo .claude/commands/commit.md:

---
description: Conventional commit, atomic split, secret scan
---
Review git status and git diff. Scan the staged files for secrets.
Split the changes into atomic commits by type/scope.
Commit using Conventional Commits. Do NOT push.

A partir daí, o time inteiro só digita /commit e tem um comportamento idêntico — chega de commits fora do padrão. É exatamente assim que você transforma um "truque pessoal" num "padrão do time".

Fluxo avançado: worktrees, revisão de PR e CI

Quando você já estiver à vontade, algumas técnicas levam a produtividade a outro nível:

Worktrees paralelas. Para o Claude Code construir um recurso na própria branch sem bagunçar o seu diretório de trabalho principal, use uma worktree:

claude --worktree feature-auth

Você pode rodar uma sessão corrigindo um bug e outra construindo um recurso em paralelo, em duas worktrees, sem uma pisar na outra.

Encaixe no pre-commit/CI. O Claude Code roda de forma não interativa com -p, então dá para colocar num script. Por exemplo, resumir os commits recentes para um changelog ou uma etapa de revisão:

git log --oneline -20 | claude -p "summarize these recent commits into a changelog"

PRs empilhados. Quando um recurso grande se divide em vários PRs dependentes (o PR B se apoia no PR A ainda não mesclado), você pode ter o Claude Code construindo a cadeia de branches empilhadas e abrindo os PRs na ordem pai-filho correta. Isso deixa os revisores aprovarem pedaços pequenos em vez de um PR gigante, e é exatamente onde uma skill de git pronta poupa muito trabalho repetitivo.

Autorrevise o PR antes de mesclar. Antes de apertar merge, deixe o Claude Code ler o diff e caçar bugs de lógica, casos extremos ou vulnerabilidades — veja como fazer o Claude revisar um PR antes do merge. Combinado com o CI do seu repositório, você ganha duas camadas de checagem: a máquina roda os testes, a IA lê o sentido da mudança. Mantenha os papéis distintos: um agente faz uma sólida primeira revisão, mas a decisão final de merge ainda deve ter olhos humanos, especialmente em mudanças que mexem com segurança ou dados.

Acelere o git com uma skill pronta (o ak-git do AgentKit)

Este artigo inteiro basicamente te ensina a montar tudo sozinha: escrever os prompts, definir as regras do CLAUDE.md, criar o slash command. Essa abordagem é perfeitamente válida e gratuita. Mas, se você preferir não montar cada peça na mão, existe uma skill de git pronta chamada ak-git que faz exatamente as quatro coisas deste artigo — conventional commits, divisão automática por type/scope, varredura de segredos e PRs empilhados — numa única chamada.

Uma linha para não confundir: o ak-git faz parte do AgentKit — o kit para Claude Code em agentkit.best (a CLI ak), que é diferente do "AgentKit" da OpenAI. Não misture os dois.

O ak-git vem do Engineer Kit ($99, o site não menciona nenhuma taxa recorrente) — se você quiser saber o que mais tem lá dentro, leia a análise do Engineer Kit antes de decidir. O ponto honesto: você não é obrigada a comprar nada para rodar esse fluxo de git — tudo neste artigo funciona com o Claude Code puro. O valor do kit é poupar o esforço de configuração e manter o comportamento consistente em um time.

Erros comuns e dicas de segurança

Deixar um agente cuidar do git é conveniente, mas há algumas armadilhas conhecidas. Veja o que costuma quebrar e como lidar:

Um limite honesto para lembrar: o Claude Code não "entende" a sua lógica de negócio tão a fundo quanto você, então às vezes as mensagens dele descrevem melhor o que mudou do que por quê. Em commits importantes, acrescente o "porquê" você mesma. E sempre revise o diff antes de aprovar — o agente é rápido, mas a responsabilidade pelo histórico ainda é sua.

Perguntas frequentes (FAQ)

O Claude Code faz push para o remoto por conta própria?

Não, a menos que você peça. Todo comando de escrita do git passa pela camada de permissões da ferramenta Bash, e o Claude Code não faz push sem você mandar. Para garantir, adicione uma regra "não faça git push por conta própria" no CLAUDE.md.

Preciso instalar o gh CLI?

Para commitar, não — só o git já basta. Mas, para o Claude Code abrir um pull request sozinho com gh pr create, você precisa do gh instalado e logado via gh auth login.

O commit inclui uma linha "Generated with Claude" e como eu desligo isso?

Por padrão, costuma haver uma linha Co-Authored-By creditando o Claude. Para desligar, adicione uma regra no CLAUDE.md: "não adicione uma linha Co-Authored-By nem qualquer assinatura de IA às mensagens de commit". O Claude Code vai remover.

Como faço o Claude dividir uma pilha de mudanças em vários commits?

Dê a instrução "divida estas mudanças em commits atômicos por type/scope". O Claude Code agrupa o diff por tópico, prepara cada grupo e então cria um commit separado por tipo de mudança.

Ele consegue abrir um pull request privado (rascunho)?

Sim. Diga "crie o PR como rascunho" e o Claude Code adiciona a flag correspondente ao rodar gh pr create. Você também pode especificar a branch de destino e os revisores.

Funciona com GitLab ou Bitbucket?

Os conventional commits, a divisão de commits e a varredura de segredos funcionam com qualquer repositório git. Só o passo automático de PR depende do gh, que é atrelado ao GitHub; para GitLab/Bitbucket use a CLI correspondente (como o glab) ou faça manualmente.

Conclusão e próximos passos

O fluxo de trabalho git com o Claude Code se resume a quatro passos: configurar o git mais o gh, escrever conventional commits corretos, dividir em commits atômicos e procurar segredos, e então abrir o PR com o gh. Coloque as regras no CLAUDE.md e num slash command /commit e o time inteiro compartilha um padrão só. Depois: encaixe o GitHub MCP para operações mais profundas do GitHub e deixe o Claude revisar o PR antes do merge. Se você preferir pular a parte de montar tudo sozinha, o bundle do AgentKit — agora $149 (de $198) já traz a skill ak-git que roda exatamente esse fluxo.