Neste capítulo você vai integrar o Claude Code ao seu fluxo de versionamento com Git: gerar mensagens de commit a partir do diff, organizar alterações em commits coerentes, resolver conflitos, investigar o histórico, desfazer mudanças indesejadas e abrir e revisar pull requests pela linha de comando. Desde o capítulo seis você usa o Git como rede de segurança; agora ele passa a ser também uma ferramenta que o Claude opera junto com você, sempre sob revisão.
Commits com mensagens geradas a partir do diff
O Claude Code executa comandos Git pelo terminal como qualquer outro comando, pedindo aprovação no modo padrão. O uso mais frequente é gerar a mensagem de commit. Depois de implementar uma alteração, peça: Revise o git diff das alterações não commitadas e proponha uma mensagem de commit. Não faça o commit ainda, só me mostre a mensagem. Ele roda git status e git diff, lê o resultado e escreve um título curto com um corpo explicando o porquê da mudança. Se estiver bom, responda que pode commitar, e ele executa git add nos arquivos certos e depois git commit.
A qualidade da mensagem depende de o Claude conhecer o padrão do time. Em vez de repetir a instrução em toda sessão, grave-a no CLAUDE.md do projeto, na seção de convenções, como você aprendeu no capítulo cinco. Um exemplo de trecho:
Commits seguem o padrão Conventional Commits: tipo, escopo entre parênteses e descrição em português no imperativo. O padrão em si não define tamanho; aqui adotamos a convenção usual do Git de até cinquenta caracteres no título e corpo quebrado em setenta e duas colunas. Tipos aceitos: feat, fix, refactor, test, docs e chore. O corpo explica a motivação, não repete o que mudou. Nunca adicione arquivos .env e nunca use git add ponto; liste os arquivos explicitamente.
Com isso, toda mensagem já sai no formato esperado, e a proibição do git add ponto evita que arquivos temporários entrem no histórico por acidente.
Branches e commits coerentes
Criar e alternar branches é direto: Crie uma branch chamada feat barra prazo-tarefa a partir da main e mude para ela. O valor real aparece quando você pede ajuda para dividir um trabalho grande em commits que contam uma história. Imagine que, ao implementar o campo de prazo do capítulo sete, você terminou com a migração, o modelo, a validação, a rota e os testes todos modificados de uma vez. Peça: Analise o diff e proponha uma divisão em commits independentes, cada um compilando e com a suíte passando. Liste quais arquivos e trechos vão em cada commit antes de executar qualquer coisa.
- Ouça o áudio com a tela desligada
- Ganhe Certificado após a conclusão
- + de 5000 cursos para você explorar!
Baixar o aplicativo
O Claude vai propor algo como: primeiro a migração e o modelo, depois a validação, depois a rota junto com os testes. Para separar trechos dentro de um mesmo arquivo, ele pode usar git add com a opção patch. Revise a proposta, ajuste o que quiser e só então autorize. Commits pequenos e coerentes facilitam a revisão por colegas e tornam o git bisect, que você conheceu no capítulo oito, muito mais preciso.
Resolvendo conflitos de merge e rebase
Conflitos são um dos melhores usos do Claude Code, porque ele lê as duas versões e o histórico ao redor delas. Quando um git merge ou um git rebase parar com conflitos, peça: Estamos no meio de um rebase com conflitos. Liste os arquivos em conflito e, para cada um, explique o que cada lado mudou e por quê, consultando o git log das duas branches. Proponha a resolução, mas não edite ainda.
Ele apresenta a intenção de cada lado. Em muitos casos a resolução é mecânica, como manter as duas adições em uma lista de imports. Em outros, as duas branches mudaram a mesma regra de negócio de formas incompatíveis, e aí a decisão é sua. Depois de aprovar a resolução, peça que ele rode a suíte de testes antes de marcar o arquivo como resolvido e continuar o rebase. Um conflito resolvido com testes verdes é um conflito resolvido de verdade; um conflito resolvido só olhando o texto é uma aposta.
Investigando o histórico
O Git guarda quem mudou o quê e, se as mensagens forem boas, por quê. O Claude Code transforma essa consulta em conversa. Alguns pedidos úteis: Use git blame em src barra services barra tarefas.js e me diga quem alterou a função calcularAtraso por último, em qual commit e o que a mensagem diz. Ou: Mostre o git log dos últimos três meses só do diretório de migrações e resuma o que mudou no esquema do banco. Ou ainda: Procure no histórico o commit que introduziu a dependência do dayjs e explique o contexto pela mensagem e pelo pull request referenciado.
Peça sempre o hash do commit na resposta. Assim você confere com git show e não depende apenas do resumo gerado.
Desfazendo alterações feitas pelo próprio Claude
Às vezes você aprova um diff e percebe depois que ele quebrou algo. Se ainda não commitou, peça: Descarte as alterações não commitadas em src barra routes barra tarefas.js com git checkout e mantenha o resto intacto. Atenção: esse descarte é definitivo, porque o que nunca foi adicionado ao índice não fica guardado em lugar nenhum do Git. Na dúvida, peça antes um git stash, que salva o trabalho e permite recuperá-lo depois. Se já commitou, prefira git revert a git reset: Crie um commit de revert do commit abc123 e rode os testes. O revert preserva o histórico e funciona mesmo que o commit já tenha sido enviado ao servidor. O git reset com a opção hard só é aceitável em commits locais que ninguém mais viu, e mesmo assim confirme com git log antes de autorizar. Lembre ainda que ele apaga também qualquer alteração não commitada no diretório de trabalho, sem possibilidade de recuperação.
Outro pedido valioso ao fim de uma sessão: Compare o estado atual com a main e liste tudo que foi alterado nesta sessão e não está relacionado ao pedido original. Isso captura mudanças de formatação ou renomeações extras que passaram despercebidas na revisão do diff.
Pull requests com o GitHub CLI
O GitHub CLI, invocado pelo comando gh, permite operar pull requests sem sair do terminal. Instale-o e autentique com gh auth login; a partir daí o Claude Code o usa como qualquer outro comando. Para abrir um pull request: Faça push da branch atual e abra um pull request para a main usando gh. Escreva a descrição com resumo, motivação, o que mudou, como testar e riscos, com base nos commits e no diff em relação à main. Me mostre a descrição antes de criar.
Quando os revisores comentarem, peça: Leia os comentários do pull request número quarenta e dois com gh pr view e gh api, agrupe por arquivo e me diga quais pedem alteração e quais são apenas dúvidas. Para cada comentário, você decide: implementar, argumentar ou perguntar. O Claude pode fazer a alteração, commitar com uma mensagem que referencia o comentário e redigir a resposta, que você lê antes de ele publicar com gh.
Revisando pull requests de outras pessoas
O caminho inverso também funciona. Peça: Faça gh pr checkout 57, leia o diff em relação à main e revise como um colega sênior: bugs prováveis, casos de borda sem teste, quebras das convenções do CLAUDE.md e riscos de segurança. Cite arquivo e linha em cada ponto e não altere nada. Você recebe uma lista que pode conferir e transformar em comentários. Trate essa revisão como um primeiro filtro, não como veredito: a IA aponta padrões suspeitos, mas quem conhece o contexto do produto é você.
Sessões paralelas com git worktrees
Um worktree do Git é um segundo diretório de trabalho ligado ao mesmo repositório, com outra branch ativa. Isso permite rodar duas sessões do Claude Code ao mesmo tempo sem que uma pise na outra: uma corrigindo um bug urgente, outra avançando uma refatoração longa. Crie o worktree com o comando a seguir, abra outro terminal nessa pasta e inicie o claude ali.
git worktree add -b hotfix/fuso-horario ../api-tarefas-fix mainA opção -b cria a branch nova a partir da main. Sem ela, o Git exige que a branch já exista e o comando falha se você informar um nome inédito.
Cada sessão tem seu próprio contexto e seus próprios arquivos; apenas o histórico é compartilhado. Ao terminar, faça commit ou push do que interessa e só então remova com git worktree remove, lembrando que o comando apaga o diretório e se recusa a rodar quando há alterações pendentes, a menos que você force. Esse padrão volta no capítulo quatorze, sobre agentes.
O que a IA nunca deve fazer sozinha
Duas operações reescrevem histórico que outras pessoas podem já ter baixado: o push forçado e o rebase ou amend de commits que já estão em uma branch compartilhada. Um push forçado errado apaga o trabalho de colegas e é difícil de recuperar. No capítulo seis você bloqueou o push forçado na lista deny do settings.json; mantenha isso. Reforce também no CLAUDE.md: Nunca faça push forçado, rebase de branches compartilhadas nem amend de commits já enviados. Se parecer necessário, explique a situação e espere aprovação explícita. Se um dia realmente precisar reescrever histórico, use a opção force-with-lease, avise o time e execute você mesmo, revisando a saída de git log antes e depois. Saiba que essa opção só protege se você não tiver feito git fetch depois de conferir o estado remoto, porque o fetch atualiza justamente a referência que ela usa como base.
Recapitulando
- Peça a mensagem de commit a partir do diff e grave o padrão do time no CLAUDE.md, proibindo git add ponto.
- Divida trabalhos grandes em commits independentes, cada um com a suíte passando, revisando a proposta antes de executar.
- Em conflitos, peça a explicação dos dois lados e rode os testes antes de concluir o merge ou rebase.
- Investigue o histórico com git blame e git log exigindo o hash do commit para conferência.
- Desfaça mudanças do Claude com git checkout ou git revert; reserve git reset para commits locais.
- Use gh para abrir pull requests com descrição gerada, tratar comentários e revisar pull requests de colegas como primeiro filtro.
- Use worktrees para sessões paralelas e nunca deixe a IA fazer push forçado ou reescrever histórico compartilhado.
