Git e GitHub: fluxo de trabalho para projetos com IA

Git e GitHub já eram a base do trabalho em equipe com software. Com agentes de IA que editam arquivos, rodam comandos e fazem commits sozinhos, eles ganharam outra função: registrar exatamente o que mudou, separar o trabalho do agente da versão que está no ar e impedir que algo seja publicado sem revisão.

Este texto descreve um fluxo de trabalho para projetos com IA montado a partir da documentação oficial do Git (git-scm.com), do GitHub (docs.github.com) e de ferramentas de agente, consultadas em 8 de outubro de 2026. Recursos e planos do GitHub mudam com frequência. Antes de configurar, confira na documentação o que vale para o seu tipo de conta e repositório.

Git e GitHub: os conceitos que você precisa

O Git é um sistema de controle de versão: ele guarda o histórico de um projeto em etapas. O GitHub é um serviço on-line que hospeda repositórios Git e acrescenta revisão, permissões e automações. Um não depende do outro, mas costumam andar juntos.

Um repositório é a pasta do projeto com todo o seu histórico.

Um commit é um registro de um conjunto de mudanças, com autor, data e mensagem. É o “ponto de salvamento” do Git.

Uma branch (ramo) é uma linha de trabalho paralela. O livro oficial Pro Git a define como um ponteiro leve e móvel para um commit. Criar uma branch é barato e quase instantâneo, o que estimula usar uma para cada tarefa.

Um pull request (PR) é um pedido, feito no GitHub, para juntar as mudanças de uma branch à branch principal. É ali que acontece a revisão.

Por que isso importa mais quando um agente escreve código

Código gerado por IA costuma parecer certo antes de estar certo. Na pesquisa do Stack Overflow de 2025, 84% dos participantes disseram usar ou planejar usar ferramentas de IA no desenvolvimento. A principal frustração, citada por 66%, foram soluções “quase certas, mas não totalmente”. E 46% disseram desconfiar da precisão das respostas.

Um agente também age em mais lugares do que um autocompletar. Em como funciona o Claude Code, mostramos que ele lê o projeto, edita arquivos, roda comandos e usa o git.

A documentação do Claude Code diz que os seus checkpoints (pontos de restauração automáticos) permitem desfazer edições de arquivos, mas são separados do git e não cobrem ações em sistemas remotos, como bancos de dados, APIs e publicações, segundo a página How Claude Code works. Um git push para o lugar errado ou um deploy não voltam com um atalho de teclado.

Por isso, o fluxo abaixo parte de uma regra simples: o agente pode errar à vontade dentro de uma área isolada, e só o que passar por revisão chega à versão principal.

O fluxo básico, adaptado para agentes

O GitHub documenta um fluxo leve chamado GitHub flow, com seis passos: criar uma branch, fazer as mudanças com commits, abrir um pull request, responder aos comentários da revisão, fazer o merge (a junção) e apagar a branch.

Em um projeto com IA, o mesmo fluxo fica assim:

1. Você descreve a tarefa ao agente.
2. O agente cria uma branch para ela e trabalha só ali.
3. Ele faz commits pequenos à medida que avança e roda os testes.
4. Ele (ou você) abre um pull request com o resumo do que mudou.
5. Uma pessoa revisa, pede ajustes e aprova.
6. As checagens automáticas passam, e só então o código entra na branch principal.

As seções seguintes detalham cada trava desse caminho.

Regra 1: o agente trabalha em uma branch própria

Segundo o GitHub flow, trabalhar em uma branch mantém a branch padrão intacta. Use nomes curtos e descritivos, que mostrem a tarefa, como corrige-login ou agente/ajusta-precos.

Se você roda mais de um agente ao mesmo tempo, ou quer continuar programando enquanto ele trabalha, use worktrees. Segundo a documentação do Git, o comando git worktree permite ter várias pastas de trabalho ligadas ao mesmo repositório, cada uma com uma branch diferente. As edições de um agente não esbarram nas suas.

O Claude Code traz esse recurso pronto. A página Common workflows mostra o comando claude --worktree nome-da-tarefa, que abre uma sessão isolada em um worktree próprio. A mesma página sugere o modo de planejamento, em que o agente propõe um plano e não edita nada até você aprovar.

O agente do GitHub Copilot que trabalha na nuvem (chamado na documentação de cloud agent) segue a mesma lógica por padrão. Segundo a página de riscos e mitigações, ele só pode enviar código para uma única branch, criada com o prefixo copilot/ quando a tarefa não parte de um PR existente, e as proteções da branch continuam valendo.

Regra 2: commits pequenos e mensagens claras

Um commit gigante com dez mudanças misturadas é difícil de revisar e impossível de desfazer pela metade. O Pro Git, na seção Contributing to a Project, recomenda que cada commit seja um conjunto de mudanças logicamente separado, com pelo menos um commit por problema.

O mesmo capítulo dá orientações práticas:

• rode git diff --check antes do commit para encontrar espaços em branco problemáticos;
• use git add --patch para incluir só parte das mudanças de um arquivo;
• escreva uma linha de resumo de até cerca de 50 caracteres, deixe uma linha em branco e explique no corpo o motivo da mudança;
• use o imperativo: “Corrige bug”, não “Corrigido bug”.

Você pode registrar essas regras no arquivo de instruções do agente (no Claude Code, o CLAUDE.md). Peça explicitamente commits pequenos, uma mudança por commit e mensagens que expliquem o porquê.

Identifique o que foi feito por IA. O GitHub registra os commits do agente do Copilot como de autoria do Copilot, com a pessoa que pediu a tarefa como coautora, para facilitar a rastreabilidade. O Claude Code também acrescenta por padrão linhas de atribuição aos commits e PRs, configuráveis, segundo a sua documentação.

Regra 3: revisão humana em todo pull request

O pull request é onde você lê o diff, a comparação linha a linha entre o código antigo e o novo. A documentação do Claude Code recomenda revisar o PR gerado antes de enviá-lo e pedir ao próprio agente que destaque riscos e pontos de atenção.

Duas configurações reforçam essa etapa:

• CODEOWNERS. Um arquivo com esse nome, em .github/, na raiz ou em docs/, define quem é responsável por cada parte do código. Segundo a documentação, essas pessoas são chamadas automaticamente para revisar PRs que mexem nos arquivos delas.
• Quem pede não aprova. No agente do Copilot, a pessoa que pediu a tarefa não pode aprovar o PR resultante, o que preserva a exigência de aprovação por outra pessoa. Os workflows do GitHub Actions (automações do repositório) também só rodam depois que alguém com permissão de escrita aprova.

Na avaliação da redação, a revisão é a etapa mais fácil de pular quando o código “parece funcionar”. É justamente nela que aparecem dependências desnecessárias, testes que só confirmam o próprio erro e mudanças fora do escopo pedido.

Regra 4: proteja a branch principal

Combinados verbais não seguram um agente com permissão de push. Regras configuradas no GitHub, sim, porque valem para qualquer conta ou aplicativo.

As branches protegidas permitem, entre outras opções:

• exigir pull request com um número mínimo de aprovações antes do merge;
• descartar aprovações antigas quando novos commits chegam;
• exigir revisão dos responsáveis definidos no CODEOWNERS;
• exigir que checagens automáticas passem, como testes, lint e verificação de tipos;
• exigir commits assinados e histórico linear;
• bloquear force push (reescrever o histórico à força) e a exclusão da branch, que vêm bloqueados por padrão;
• aplicar as regras também aos administradores.

Os rulesets são a alternativa mais recente. Segundo a documentação, vários rulesets podem valer para a mesma branch ao mesmo tempo, e quando duas regras conflitam vale a mais restritiva. Eles também podem ser ligados e desligados sem ser apagados.

Para as checagens obrigatórias, escolha o que o agente não consegue “convencer”: testes automatizados, o build do projeto e, em projetos JavaScript, a verificação de tipos. Explicamos por que os tipos pegam boa parte dos erros de código gerado por IA em TypeScript: por que adotá-lo.

Regra 5: segredos fora do repositório

Senhas, chaves de API e tokens (credenciais de acesso) não devem entrar no Git. Uma vez num commit, ficam no histórico mesmo depois de apagados do arquivo.

O risco é concreto. Segundo relatório da empresa de segurança GitGuardian divulgado em 17 de março de 2026, cerca de 29 milhões de segredos foram detectados em commits públicos no GitHub em 2025, alta de 34% em um ano. A empresa afirma que commits feitos com ajuda do Claude Code vazaram segredos em cerca de 3,2% dos casos, o dobro da média geral. São medições da própria GitGuardian, que vende produtos de segurança, com metodologia pouco detalhada no comunicado. E uma taxa maior não prova que a ferramenta cause o vazamento: o próprio texto diz que os casos podem refletir erros humanos.

Três camadas ajudam:

1. O arquivo .gitignore. Ele lista arquivos que o Git deve ignorar, como o .env com credenciais locais. Atenção ao detalhe da documentação: arquivos que o Git já rastreia não são afetados. Se o .env já entrou num commit, é preciso tirá-lo do índice com git rm --cached.
2. A varredura de segredos (secret scanning). O GitHub procura credenciais em todo o histórico de todas as branches, além de issues e pull requests. Segundo a documentação, ela é automática e gratuita em repositórios públicos. Em repositórios privados de organizações, depende do produto pago GitHub Secret Protection.
3. A proteção de push (push protection). Em vez de avisar depois, ela bloqueia o envio que contém um segredo e explica o motivo. A versão para usuários vem ligada por padrão e impede enviar segredos a repositórios públicos no GitHub.com. A versão por repositório precisa ser ativada. Quem contorna o bloqueio precisa justificar, e o contorno fica registrado.

Se um segredo vazar, a orientação do GitHub é revogar e trocar a credencial imediatamente. Limpar o histórico é trabalhoso e, depois que a chave foi revogada, muitas vezes desnecessário.

Lista de verificação para o seu repositório

• A branch principal está protegida e só recebe código por pull request.
• Pelo menos uma aprovação humana é exigida, e aprovações antigas caem com novos commits.
• Testes, build e verificação de tipos são checagens obrigatórias.
• O agente trabalha em branch própria, de preferência em um worktree separado.
• O arquivo de instruções do agente pede commits pequenos e mensagens explicativas.
• O .gitignore cobre .env e outros arquivos com credenciais.
• A varredura de segredos e a proteção de push estão ativas onde o seu plano permite.
• O agente não tem permissão para fazer push direto, deploy ou alterar configurações de produção sem pedir.

O que levar deste texto

Com agentes de IA, o Git deixa de ser só histórico e vira o perímetro de segurança do projeto. O agente pode experimentar à vontade numa branch isolada. O que chega à versão principal passa por pull request, revisão humana e checagens automáticas.

As travas mais eficazes são as configuradas no GitHub, porque valem igualmente para pessoas e agentes: branches protegidas, revisão obrigatória, testes e tipos como condição de merge, varredura e bloqueio de segredos.

Se você está começando um produto com essas ferramentas, veja também como construir um MVP com agentes de IA e como medir produtividade em projetos com IA.