Pull Request no Git: Seu guia sobre como funciona

Os pull requests ajudaram minhas equipes a evitar bugs, se alinhar nas decisões de implementação e aprender com o código uns dos outros. Neste guia, vou te mostrar como usar pull requests em plataformas baseadas em Git para revisar seu código com segurança.

Se você está começando com o Git, recomendo fazernossos cursos Introdução ao Git e Introdução aos conceitos do GitHub para aprender sobre controle de versão e as diferenças entre o Git e o GitHub. Além disso, acho que o Git Cheat Sheet, que você pode baixar, é umareferência útilporque tem todas as terminologias e comandos mais comuns do Git.

O que é um Pull Request?

Um pull request é basicamente uma forma de sugerir mudanças no código. Então, imagina que você está trabalhando em um recurso ou em um ramo separado. Uma solicitação pull permite que você peça para mesclar essas alterações na base de código principal. Isso geralmente é feito depois que outras pessoas já tiveram a chance de revisá-los. Os pull requests são uma parte essencial do desenvolvimento colaborativo, principalmente quando se trabalha em equipe.

Vale a pena notar que no GitLab, esse mesmo processo é chamado de “Solicitação de mesclagem”. 

Como funciona um pedido de pull?

Os passos a seguir mostram o fluxo de trabalho básico de uma solicitação pull:

1. Faz alterações no script (código) em um ramo de recurso.
2. Salve essas mudanças no seu repositório local.
3. Envie o branch para o repositório remoto, como o GitHub.
4. Abra uma solicitação pull para sugerir as alterações na ramificação principal.
5. Peça pra dar uma olhada nas mudanças que propusemos.
6. Junta ou fecha a solicitação de pull, dependendo do resultado.

Esse fluxo de trabalho dá a todos os desenvolvedores a chance de revisar o código e identificar possíveis problemas antes de enviar o código para produção ao vivo.

Os papéis principais no processo de solicitação de pull incluem o seguinte:

• Colaborador: O desenvolvedor que faz as alterações e abre a solicitação pull.
• Revisor: É o desenvolvedor que analisa as alterações propostas no código para sugerir melhorias e garantir a qualidade do código.
• Maintainer: O gerente de projeto que é responsável pelo projeto e tem permissão para aprovar ou rejeitar solicitações de pull. 

Recomendo fazer nosso curso Git Intermediário pra aprender acriar branches no Git e a colaborar remotamente com os membros da equipe.

Criando uma solicitação pull (com um exemplo)

Digamos que você percebeu um erro na linha de introdução do arquivo README do seu projeto. Você quer resolver esse problema sem mexer na ramificação principal. Siga os passos abaixo:

Passo 1: Criar um novo ramo

Vá até a pasta do seu projeto e abra o terminal para rodar o comando abaixo. Essa linha cria outro ramo.

git checkout -b fix-readme-typo

Passo 2: Mude a sua vida

Para corrigir o arquivo, abra o arquivo “ README.md ” no seu editor de código, corrija o erro e salve o arquivo.

Passo 3: Confirme as alterações

Prepare e confirme as alterações usando o comando abaixo:

git add README.md
git commit -m "Fix typo in README"

Passo 4: Envie o branch para o GitHub

Carregue o branch para o repositório.

git push origin fix-readme-typo

Passo 5: Abra o GitHub e crie uma solicitação pull.

Agora, abre a tua conta GitHub e faz o seguinte:

• Vá até o seu repositório no GitHub.

• Escolha a opção Comparar e solicitar pull para o seu branch enviado.

• Adicione um título como “Corrigir erro ortográfico no README” e, se quiser, escreva uma breve descrição.

• Escolha o seu ramo base (normalmente main) e compare-o com o seu ramo de recurso.

Passo 6: Pede revisão e manda

Se o seu projeto envolve outros desenvolvedores, você pode pedir revisores ou adicionar etiquetas, se o projeto usar isso. Depois, clica em“ ” e “Create pull request”.

Dá uma olhada no nosso projeto sobre Como fazer uma revisão de código pra entender como revisar e fazer alterações antes de enviar o código pra produção.

Melhores práticas para pull requests

Aqui estão as melhores práticas para garantir um desenvolvimento de qualidade ao criar pull requests:

• Mantenha suas solicitações de pull curtas e simples: Comece sempre com um pedido de pull para cada recurso que você gostaria de sugerir. Isso ajuda o revisor a acompanhar e testar suas alterações e minimiza a possibilidade de introduzir um bug.
• Escreva mensagens e descrições claras de commit: Manda mensagens de commit que expliquem as edições. Esse contexto ajuda os revisores a entender sua intenção sem precisar vasculhar o código.  
• Aproveite os pedidos de pull draft para obter feedback antecipado: Se o seu trabalho não está pronto, mas você quer saber o que achamos, crie um pedido de pull request. Isso mostra que seu código ainda está sendo trabalhado e pede uma conversa, sem precisar juntar tudo de uma vez.
• Teste tudo direitinho e compartilhe o contexto: Sempre dá uma conferida nas alterações pra garantir que tudo tá funcionando como você quer.

Pull requests em fluxos de trabalho Git

Aqui vai uma visão geral rápida de como diferentes configurações de equipe usam pull requests.

• Ramificação de recursos: Isso é comum em equipes pequenas e repositórios privados. Esse fluxo de trabalho envolve criar um novo ramo para cada recurso. 

• Fluxo de trabalho de bifurcação: Esse fluxo de trabalho é usado em projetos de código aberto. O fluxo de trabalho de bifurcação exige que os colaboradores bifurquem (copiem) o repositório principal para a conta deles. Eles fazem alterações em sua bifurcação e, em seguida, abrem uma solicitação pull para o original.

• GitFlow: Esse é um fluxo de trabalho estruturado que usa ramificações de longo prazo, como main, develop, release e hotfix. É usado por equipes maiores com ciclos de lançamento mais complexos.

Etiqueta para solicitações de pull

É possível que ocorram problemas, por isso as solicitações de pull vêm com seu próprio tipo de etiqueta:

• Seja respeitoso e específico: Concentre-se no código, não no indivíduo.
• Mantenha as solicitações de pull focadas: Evite misturar alterações não relacionadas em uma única solicitação pull. Isso só complica a revisão e o feedback.
• Responda com cuidado aos comentários: Dá um feedback positivo pra quem escreve código legal e faz sugestões pra melhorar.
• Não deixe os pull requests ficarem muito tempo sem resposta: Tente sempre revisar e resolver as solicitações de pull o mais rápido possível para evitar atrasos nas atualizações.
• Faça perguntas: Se algo não estiver claro, peça esclarecimentos em vez de presumir a intenção, para evitar mal-entendidos.
• Dá uma sugestão pra gente: Quando for o caso, dá conselhos práticos ou sugere abordagens alternativas, em vez de só apontar os problemas.

Fluxos de trabalho avançados para solicitações de pull e melhores práticas

Se você é um desenvolvedor experiente e quer facilitar a colaboração, melhorar a qualidade do código e expandir seu processo de pull request, aqui vão algumas dicas práticas para deixar seu fluxo de trabalho mais eficiente.

Fluxos de trabalho mais inteligentes

Vários fluxos de trabalho do Git lidam com solicitações de pull de maneiras diferentes. Como falamos antes, o Feature Branching é perfeito para equipes pequenas por ser bem simples. Mas, pode ser complicado manter isso se você tiver uma equipe que tá crescendo.

A bifurcação é recomendada para projetos de código aberto, mas pode trazer um pouco de trabalho extra na hora de sincronizar e revisar contribuições externas. Da mesma forma, o GitFlow é recomendado em desenvolvimentos rápidos, embora sua complexidade possa tornar o processo mais lento. 

Automação e integração

Os pull requests modernos têm as verificações CI/CD, que automatizam os controles de qualidade integrando ferramentas de integração contínua que fazem testes e linters e implementam pré-visualizações em cada PR. Isso garante que só o código que passa nos padrões definidos vai ser mesclado.

Plataformas como GitHub Actions e GitLab Pipelines também permitem a automação. Esses processos incluem a execução de testes unitários, a criação e implantação de ambientes de pré-visualização, a redução do trabalho manual e a detecção precoce de problemas.

Otimizando avaliações

Mantenha sempre as solicitações de pull pequenas e focadas para que possam ser revisadas de forma rápida e completa. Usar modelos com campos claros, como “O que mudou” e “Como testar”, ajuda os colaboradores a fornecer informações concisas e relevantes, tornando as revisões mais eficientes.

Também é importante lembrar que fazer perguntas em vez de exigir coisas ajuda a ter um papo construtivo e a aprender mais. Se você definir prazos para revisões, vai manter o processo previsível e evitar atrasos.

Métricas e ferramentas modernas

Também recomendo que você acompanhe o tamanho do PR, o tempo de revisão e a taxa de mesclagem para identificar gargalos e melhorar a eficiência do fluxo de trabalho. Para facilitar as revisões e a fusão, tente usar uma solicitação pull empilhada. Isso dividiria recursos grandes em PRs menores e conectados que se complementam. 

Além disso, você pode integrar ferramentas de IA como GitHub Copilot ou CodeWhisperer ao usar pull requests. Essas ferramentas vão te ajudar a identificar possíveis problemas logo de cara e sugerir como resolver.

Pull Requests vs. Solicitações de mesclagem

No GitHub e no GitLab, Pull Requests (PR) e Merge Requests (MR) são usados da mesma forma. Mesmo que tenham a mesma finalidade, cada plataforma lida com eles de maneira diferente.

A tabela abaixo compara PRs e MRs para mostrar essas diferenças.

Conclusão

Os pull requests são algo que todo mundo precisa saber em projetos sérios. Como você viu (e espero que agora entenda), eles permitem que as equipes revisem, discutam e melhorem o código de forma colaborativa.

Continue aprimorando suas habilidades como desenvolvedor. Dá uma olhada nos nossos programas de habilidades Fundamentos do Git e Fundamentos do GitHub para se tornar um especialista em tudo que é relacionado ao Git.