O que é uma pull request?

Uma pull request (PR) é um método para propor alterações em uma base de código. Os desenvolvedores de software dividem o repositório de código principal (também chamado de repo) em uma ramificação separada, enviam o código para essa ramificação enquanto trabalham e criam uma pull request para sinalizar as alterações sugeridas para avaliação do código antes de extrair ou mesclar as alterações da ramificação na base de código principal.

As PRs são mecanismos comuns em repositórios Git, como Bitbucket e GitHub. O GitLab aplica o termo "merge request" em vez de pull request para o mesmo processo.

Os desenvolvedores podem criar pull request usando a interface de linha de comando (CLI) ou a interface da web. Novas pull requests são normalmente abertas para correções de bugs, atualizações de dependências, novas funcionalidades ou código refatorado. As pull requests simplificam as avaliações de código, mantêm as bases de código atualizadas e promovem a colaboração entre os membros das equipes de desenvolvimento de software.

As PRs permitem que os desenvolvedores criem código-fonte e o testem localmente. Como as alterações do código são isoladas da ramificação principal, os desenvolvedores não precisam se preocupar em quebrar toda a base de código.

A metodologia pull request envolve três funções vitais que se aplicam principalmente a projetos de código aberto, mas também podem ser adotadas por projetos proprietários ou de código fechado:

• Mantenedores: os mantenedores do projeto gerenciam (e, muitas vezes, são os proprietários) do projeto e têm autoridade para aprovar e mesclar PRs ou rejeitá-las.

• Revisores: esses membros da equipe (que podem ser mantenedores ou outros colaboradores ativos com muita experiência no projeto) revisam as alterações propostas para a qualidade do código e sugerem melhorias conforme consideram necessário.

• Colaboradores: esses desenvolvedores têm a tarefa de fazer alterações e abrir pull requests.

A criação de pull requests geralmente envolve um procedimento de sete etapas:

1. Um colaborador faz uma derivação do repositório principal para criar uma nova ramificação (usando o comando git checkout ou a interface web) e clona essa ramificação em sua máquina local.
   
   
2. O colaborador trabalha em suas alterações e compromete o código localmente para a ramificação.
   
   
3. Depois que o colaborador termina e testa seu código, ele primeiro extrai as atualizações mais recentes do repositório principal para evitar quaisquer alterações conflitantes antes de enviar seu código.
   
   
4. O colaborador abre uma nova pull request para que suas alterações propostas sejam integradas à ramificação principal.
   
   
5. Os revisores recebem notificações quando as pull requests são enviadas. Eles verificam a PR para comparar as diferenças (também chamadas de diffs) entre a ramificação do colaborador e a ramificação principal, fazendo avaliações do código e comentando áreas que precisam de otimização ou melhoria.
   
   
6. Os colaboradores fazem compromissos adicionais com base nas sugestões e solicitações de mudança do revisor.
   
   
7. Quando todas as alterações forem implementadas, o revisor notifica o mantenedor, que aprova a PR. A pull request é, então, mesclada no repositório principal.

As equipes de desenvolvimento de software podem escolher entre várias opções de fluxo de trabalho de RP, dependendo de suas necessidades. Os fluxos de trabalho comuns de pull requests incluem:

• Fluxo de trabalho de ramificação de funcionalidade

• Fluxo de trabalho de bifurcação

• git-flow

• Fluxo de trabalho em stack

Cada nova funcionalidade recebe sua própria ramificação dedicada, com um nome descritivo para destacar a finalidade da funcionalidade. Quando a funcionalidade estiver concluída, os desenvolvedores podem enviar a ramificação da funcionalidade para a ramificação principal e criar uma pull request.

Esse fluxo de trabalho mantém a estabilidade da ramificação principal, pois os colaboradores trabalham separadamente nas funcionalidades. Mas gerenciar múltiplas ramificações de funcionalidades pode se tornar difícil.

O procedimento de sete etapas descrito na seção anterior sobre a criação de pull requests corresponde a um fluxo de trabalho de bifurcação. Projetos de código aberto geralmente empregam esse fluxo de trabalho, que também complementa as práticas de integraçãocontínua/entrega contínua(CI/CD). O fluxo do GitHub segue um processo semelhante ao fluxo de trabalho de bifurcação.

O engenheiro de software Vincent Driessen formulou o git-flow em 2010. Normalmente, é usado para construir softwares com cronogramas de lançamento rigorosos ou aqueles que são compatíveis com várias versões.

Esse fluxo de trabalho segue um modelo de ramificação composto por estas ramificações:

• main contém a versão estável mais recente

• develop atua como um ramo de integração para correções de bugs, funcionalidades e outras alterações de código incluídas na próxima versão

• feature usa o desenvolvimento como sua ramificação de origem e uma ramificação de destino, com funcionalidades mescladas no desenvolvimento quando estiverem prontas

• release é derivado do desenvolvimento e marcado com o número da versão para a próxima versão, então mesclado no desenvolvimento e no main assim que estiver pronto para ser enviado

• hotfix é derivado diretamente do main para corrigir qualquer problema de produção de alta prioridade ou alta gravidade, e então mesclado no develop e no main assim que as correções são feitas

Os desenvolvedores criam pull requests para ramificações hotfix , feature e release , que precisam de avaliações.

Um fluxo de trabalho em stack divide grandes tarefas em uma sequência de pequenas alterações incrementais no código. A próxima alteração de código depende da anterior; portanto, as pull requests são criadas umas sobre as outras.

Considere uma funcionalidade que envolva mudanças nessas funções: o banco de dados ou modelo de dados, API e front-end. Na ramificação de funcionalidades convencional ou no fluxo de trabalho de bifurcação, um colaborador deve aguardar a PR das alterações no banco de dados ou no modelo de dados serem avaliadas, aprovadas e mescladas na ramificação principal antes que possam iniciar as atualizações da API. Em um fluxo de trabalho em stack, esse período de espera é eliminado — o colaborador pode sair das ramificações das mudanças no banco de dados ou no modelo de dados para começar a trabalhar na API, enviar uma PR para isso e ramificar as mudanças na API para lidar com as tarefas de front-end.

As pull requests oferecem estas vantagens:

• Cultiva a colaboração

• Melhora a qualidade do código

• Aumenta a transparência

• Fortalece as habilidades de programação

As pull requests promovem a cooperação, incentivando os membros da equipe a trabalharem juntos, independentemente de sua função. As PRs facilitam o feedback e como lidar com ele, iniciar discussões e gerar ideias para refinamentos.

As PRs iniciam o processo de avaliação do código, ajudando a identificar bugs, desvios do estilo e dos padrões de programação, problemas de desempenho e vulnerabilidades de segurança. Essa supervisão adicional mantém ou até mesmo melhora a qualidade do código.

As pull requests permitem que as equipes vejam quais mudanças foram implementadas, quem as fez, onde foram aplicadas e os motivos por trás delas. Essa visibilidade fornece melhores insights sobre o estado da base de código e do próprio projeto.

Tanto os revisores quanto os colaboradores podem aprender uns com os outros, adquirindo novas técnicas ao longo do caminho e descobrindo novas abordagens para os problemas. Iniciantes e novos membros da equipe também podem estudar as PRs anteriores para entender melhor a base de código e se atualizar sobre os padrões de programação e as melhores práticas da equipe.

Embora criar pull requests pareça simples, aqui estão algumas dicas e truques que podem facilitar ainda mais o processo:

• Considere rascunhos

• Os detalhes são importantes

• Mantenha o foco

• Fique por dentro das novidades

• Adote modelos

Os rascunhos de pull requests ou solicitações de mesclagem servem como um caminho para os desenvolvedores compartilharem seu trabalho em andamento. Isso permite que os membros da equipe iniciem as colaborações mais cedo e solicitam feedback mais rápido, para que aqueles que estiverem presos a um problema possam contar com o crowdsourcing de possíveis soluções de seus colegas de equipe.

Os desenvolvedores devem fornecer mensagens claras, concisas e específicas para seus novos compromissos. Clareza, concisão e especificidade também se aplicam aos títulos e descrições de PRs, tornando mais fácil e rápido para os revisores perceber a intenção por trás das alterações de código.

Agrupar vários problemas em uma única PR pode resultar em tempos de avaliação mais longos e mais revisões. Cada pull request deve tratar de apenas uma correção de bug ou funcionalidade. Pull requests focadas podem levar a avaliações de código mais eficientes.

Antes de enviar o código e abrir uma PR, os desenvolvedores devem verificar se sua ramificação está atualizada. Escolher as últimas alterações e quaisquer novos compromissos evita conflitos depois que a pull request for mesclada. Eles podem usar o comando git pull para buscar e mesclar alterações da ramificação de destino ou o comando git rebase para um histórico limpo de compromissos do git.

Os modelos de descrição de PRs ajudam a garantir a consistência e apresentam um contexto vital para simplificar as avaliações de código. As equipes podem criar um modelo para diferentes tipos de pull requests, como correções de bugs, funcionalidades ou código refatorado.

Os modelos geralmente são escritos usando a linguagem de marcação Markdown e colocados na pasta raiz ou na ramificação principal do repositório do projeto. Os campos típicos incluem:

• Descrição do problema ou da funcionalidade (com um link para o ticket correspondente no Jira ou outro software de rastreamento de problemas para referência)

• Solução descrevendo as alterações de código em detalhes

• Testes, como casos de teste de unidade ou integração, cobertura de teste e etapas para validar manualmente a solução, se aplicável

• Alterações na configuração

• Lista de verificação de tarefas relevantes, como documentação de código e compilações de código limpo sem erros ou avisos

Automatizar PRs pode acelerar o ciclo de vida de uma pull request desde a criação até a avaliação e a fusão. A automação de PRs engloba uma camada de sistemas que ajudam a reduzir os gargalos:

• PRs em stack

• Pipelines de CI/CD

• Sistemas de gerenciamento de SDLC

• Assistentes de programação impulsionados por IA

A maioria dos repositórios Git não é projetada para ser compatível com um fluxo de trabalho em stack, mas algumas ferramentas abstraem a complexidade de sincronizar pull requests em stack e lidar com conflitos de mesclagem. Essas ferramentas incluem a plataforma Graphite, que possui uma CLI e uma extensão para o VS Code da Microsoft para PRs em stack e uma interface web para gerenciá-los; O sistema de gerenciamento de código fonte Sapling da Meta; e a CLI do ghstack de código aberto para enviar diffs em stack para o GitHub como pull requests separadas.

Como um fluxo de trabalho automatizado de DevOps, o pipeline de CI/CD ajuda a garantir a qualidade do código. Plataformas como GitHub Actions e GitLab e outras ferramentas de CI podem executar testes de unidade e testes de integração e implementar ambientes de visualização que atuam como áreas de testes para visualizar e testar alterações de código em PRs.

Os pipelines de CI/CD também reforçam práticas seguras de programação. Analisadores de código estático e outras ferramentas de teste estático de segurança de aplicações (SAST) integram-se sem dificuldades à maioria dos ambientes de CI/CD para identificar vulnerabilidades de código prováveis. As equipes de DevOps podem implementar ganchos de pré-compromisso para detecção de segredos, tornando a varredura de segredos uma etapa obrigatória antes que os desenvolvedores comprometam o código ou iniciem pull requests e bloqueando alterações que contenham segredos codificados.

Plataformas como Jira e IBM Engineering Lifecycle Management (ELM) são compatíveis com o rastreamento e gerenciamento de pull requests ao longo do ciclo de vida de desenvolvimento de software (SDLC).

Como parte do pacote ELM, o IBM Engineering Workflow Management (EWM) e o IBM Engineering Integration Hub incorporam a automação de PRs diretamente aos fluxos de trabalho de desenvolvimento. O EWM pode se conectar aos repositórios Git por meio dos conectores do Hub e acionar a criação de PRs a partir de itens de trabalho. Quando um requisito ou solicitação de alteração é aprovado no EWM, uma regra pode abrir automaticamente uma pull request no repositório Git vinculado e preencher previamente a descrição.

As automações orientadas por IA no ELM também podem executar análises estáticas e pacotes de testes assim que a PR é aberta, postando resultados de volta no item de trabalho e bloqueando a mesclagem até que os critérios sejam atendidos. Enquanto isso, o Hub sincroniza o status da PR entre as ferramentas, refletindo-o no repositório e nos dashboard de EWM para visibilidade em tempo real.

Assistentes de programação impulsionados por IA, como o GitHub Copilot e o IBM Bob, podem aumentar os fluxos de trabalho de pull requests. Por exemplo, o Bob pode gerar mensagens de compromissos bem formatadas e significativas. Ele examina o nome da ramificação e o histórico de compromissos para corresponder às convenções de estilo de um projeto.

O Bob também pode criar uma pull request diretamente a partir do IDE de um desenvolvedor. Ele analisa o nome da ramificação, as alterações no código e o histórico de compromissos para entender a finalidade e o escopo. Em seguida, ele gera um título de PR e uma descrição detalhada que resume as alterações, detectando e usando automaticamente os modelos de PRs existentes de um projeto para descrições de pull requests.