Neste artigo, o(a) senhor(a) vai entender o que é um Pull Request (PR), por que ele serve para discutir alterações e como criar e revisar PRs direto na IDE. Também vamos passar por três regras para um bom commit. É uma base importante: Claude Code pode preparar e comentar um pull request pelo(a) senhor(a). Entender o que é um PR e para que serve ajuda a usar esse recurso com consciência.
Os exemplos e as capturas de tela são da IDE da JetBrains; os nomes e a localização das ações podem variar conforme a sua versão. Para os exercícios, use um repositório separado para prática. Em um projeto de trabalho, siga as regras dele para branches, commits e envio das alterações.
Por que usar Pull Requests
Em uma equipe, vale a pena discutir as alterações antes de incorporá-las à branch compartilhada. O pull request reúne em um só lugar o diff proposto, os comentários de revisão e os resultados das verificações. Ele também é usado em projetos pessoais, quando alguém quer revisar o próprio trabalho antes do merge.
Em um fluxo de trabalho com PR, o primeiro passo é criar uma proposta de merge. No GitHub, ela se chama Pull Request; em algumas outras plataformas, Merge Request. A equipe define o processo específico.
Um Pull Request é um pedido formal: "por favor, pegue (pull) as minhas alterações da minha branch e adicione-as (merge) à branch principal". Mas não é só um pedido: é também um espaço para discutir, verificar e melhorar o código antes que ele chegue à main.
Claude Code pode preparar o título, a descrição e uma análise do PR, por exemplo, com o GitHub CLI. Confira o rascunho primeiro. Criar um PR ou enviar um comentário já altera o GitHub; isso só acontece quando o(a) senhor(a) solicita.
Fluxo padrão de trabalho com Pull Request
Vamos ver, passo a passo, como costuma ser o processo para adicionar uma nova funcionalidade.
Antes de criar uma branch, confira a branch de origem e a lista de commits dela em relação à branch de destino no GitHub. Commits locais que não têm relação com a tarefa não devem entrar no novo PR. Não os envie automaticamente só para "sincronizar": escolha a base certa para a tarefa e mantenha o trabalho anterior separado.
Etapa 1. Crie uma branch para a nova tarefa. No fluxo de PR mostrado aqui, o trabalho começa em uma branch separada. Digamos que queiramos adicionar um arquivo com orientações para quem contribui: vamos criar a branch feature/add-contribution-guide.
Etapa 2. Faça as alterações e envie a branch ao GitHub. Na nova branch, crie o arquivo CONTRIBUTING.md (depois de criá-lo, clique em Add) e escreva uma mensagem para os outros desenvolvedores. Em seguida, use Commit and Push com uma mensagem clara, por exemplo, docs: Add contribution guide.
Esta é a etapa principal. O Pull Request é criado a partir de uma branch que já existe no servidor remoto. Por isso, antes de criar o PR, é essencial enviar (push) a nova branch ao GitHub.
Como criar um Pull Request na IDE
Confira os dois lados da comparação: base é a branch para a qual as alterações são propostas; compare/head é a branch com o seu trabalho. Revise a lista de commits e o diff antes de criar o PR.
Agora que a sua branch está no GitHub, já é possível criar um Pull Request.
Etapa 1. Abra a aba Pull Requests. Na barra lateral esquerda da IDE, encontre a aba Pull Requests. Abra-a e clique no ícone + (ou no botão Create Pull Request).
Etapa 2. Preencha os dados do PR. A IDE abrirá uma interface prática. Cabe ao(à) senhor(a) preenchê-la com cuidado. Os principais campos são:
- título - a IDE costuma preencher esse campo com o nome da branch ou a mensagem do último commit; confira se o título é curto, claro e resume as alterações;
- descrição - explique aos colegas em detalhes o que o(a) senhor(a) fez e por quê;
- revisores (Reviewers) - as pessoas que o(a) senhor(a) convida para revisar as alterações. As regras do repositório definem se a aprovação é obrigatória;
- responsáveis (Assignees) - normalmente, o(a) senhor(a) indica a si mesmo(a) como autor(a) e responsável pelas correções depois da revisão.
Antes de clicar em Create Pull Request, confira mais uma vez base, head e diff. Se o trabalho ainda não estiver pronto para revisão, é possível criar um Draft PR, quando essa opção estiver disponível. Tanto o PR normal quanto o draft já ficam visíveis para quem tem acesso ao repositório.
Code review: revisão e discussão
Depois de criar o PR, começa a etapa mais importante: code review. Os colegas podem abrir o seu PR, conferir todas as alterações e deixar comentários.
As discussões ficam visíveis direto na IDE, na aba Pull Requests. Se alguém comentar uma linha de código, o(a) senhor(a) recebe uma notificação e pode responder sem precisar ir para o navegador.
O que fazer se pedirem ajustes? É simples: não precisa criar outro PR. Faça as alterações na branch de origem deste PR, crie um novo commit e envie-o. O Pull Request no GitHub será atualizado automaticamente, com os novos commits acrescentados à discussão existente.
Claude Code pode participar do code review: analisar as alterações do PR e deixar comentários. É útil como um primeiro par de olhos, mas a decisão final e a responsabilidade pelo código continuam com o(a) senhor(a) e a equipe.
Conclusão: merge e exclusão da branch
Quando todos os comentários forem resolvidos e a equipe aprovar as alterações, ou seja, quando o(a) senhor(a) receber o "approve", o Pull Request pode ser integrado. Em geral, quem faz isso é um desenvolvedor sênior ou o(a) senhor(a), se tiver essa permissão no repositório.
Etapa 1. Merge. Confira os comentários, as aprovações obrigatórias e o status das verificações. Se as regras e as permissões permitirem o merge, escolha um dos métodos disponíveis (merge, squash ou rebase) conforme as regras do projeto e confirme. As alterações entrarão na branch de destino do PR, que, no nosso exemplo, é main.
Etapa 2. Exclua a branch. Depois do merge, a feature branch não é mais necessária. Vale excluí-la para não deixar o repositório cheio de branches antigas. O GitHub oferece essa opção no botão Delete branch.
Depois do merge, mude localmente para main, obtenha as atualizações e confira se o resultado do PR está lá. Em seguida, o(a) senhor(a) pode excluir a branch local da tarefa, se não houver mais trabalho necessário nela. Se a IDE não permitir excluí-la do jeito habitual, primeiro descubra o motivo, especialmente depois de um squash ou rebase.
Três regras para um bom commit
Um bom commit não depende apenas de uma mensagem adequada, mas também do conteúdo. Para manter o histórico de alterações organizado e útil, siga estas três regras simples.
Regra 1: escreva mensagens claras
Seus commits são mensagens para a equipe e para o(a) senhor(a) no futuro. Um histórico cheio apenas de "fix" ou "update" é inútil. Um formato bastante usado é Conventional Commits, que propõe esta estrutura:
<tipo>: <descrição curta>
Tipo é uma palavra curta que descreve a categoria da alteração:
feat- nova funcionalidade;fix- correção de um erro;docs- alterações na documentação;style- ajustes de formatação que não afetam a lógica;refactor- alterações no código sem nova funcionalidade nem correção de erros;test- inclusão ou correção de testes;chore- tarefas rotineiras (atualização de dependências, configuração do build).
Exemplos:
- Ruim:
fixed bug - Bom:
fix: Correct user login validation - Ruim:
readme - Bom:
docs: Update installation instructions
Peça ao Claude Code que use o formato de mensagens adotado no repositório. Conventional Commits é opcional se a equipe tiver escolhido outro padrão.
Regra 2: um commit, uma alteração lógica
Não tente colocar em um único commit uma correção de bug, uma funcionalidade nova e uma refatoração do código antigo. Um commit assim é difícil de revisar e quase impossível de reverter sem complicações. Cada commit deve resolver uma tarefa específica.
- Ruim: um único commit "Update user page" que adiciona um campo de avatar, corrige a validação do nome e muda a cor dos botões;
- Bom: três commits separados:
feat: Add avatar upload to user profilefix: Correct username validation logicfeat: Update button colors on user page
Se, no embalo do trabalho, o(a) senhor(a) alterou coisa demais em um arquivo, a IDE permite fazer commit de apenas parte dele. Na janela Commit, expanda o arquivo e marque somente os trechos (chunks) relacionados à tarefa.
Regra 3: confira o resultado das alterações
Antes do merge, execute as verificações adequadas às alterações e confira os resultados reais. Uma alteração na documentação e uma lógica nova pedem conjuntos de verificações diferentes.
Se o repositório já tiver verificações automáticas configuradas, o PR mostrará o status delas. Uma marca verde indica que as verificações executadas passaram; não prova que não há erros. Veja o que foi executado e o que ainda não foi verificado. Configurar a automação é outro assunto.
Como Claude Code pode ajudar
O PR é um ponto em que Claude Code pode ser especialmente útil. Veja como:
- Claude pode criar um pull request da sua branch com título e descrição prontos; o(a) senhor(a) confere o texto antes da criação do PR no GitHub;
- pode analisar as alterações do PR e deixar comentários como uma primeira revisão;
- ajuda a redigir mensagens de commit de acordo com as regras do projeto;
- pode ajudar a interpretar os resultados das verificações já configuradas e apontar o que não foi conferido.
O PR existe para que o código seja revisado antes de chegar à main. Mesmo que Claude Code tenha preparado a descrição e feito parte da revisão, a aprovação final e a responsabilidade pelo merge são de uma pessoa. Leia o que será integrado antes de clicar em Merge.
Artigo anterior: Branches e merge no Git · Próximo artigo: Como desfazer e recuperar alterações no Git
GO TO FULL VERSION