Revisando Pull Request
Esta página explica como os revisores podem avaliar pull requests, solicitar alterações, aprová-los e lidar com conflitos antes do merge.
Depois de criar um pull request (PR), o próximo passo é revisar as alterações antes de mesclar. As revisões garantem a qualidade do código, detectam conflitos cedo e aplicam fluxos de aprovação da equipe.
Se nenhum revisor for adicionado, você ainda pode agir como revisor e prosseguir com o processo de revisão.
Painéis de visão geral do Pull Request
Quando você abre um pull request, a página Visão Geral exibe dois painéis principais:
Painel esquerdo – Detalhes do Pull Request
Esta seção resume as informações principais do PR:
Status – estado atual (Criado, Revisão Solicitada, Alterações Solicitadas, Aprovado).
Branch de destino – o branch onde as alterações serão mescladas.
Branch de origem – o branch de onde as alterações se originam.
Criado por – usuário que abriu o PR.
Data de criação – quando o PR foi aberto pela primeira vez.
Data de atualização – última atividade ou alteração no PR.
Descrição – resumo das alterações fornecido pelo autor do PR.
Este painel dá aos revisores e colaboradores contexto imediato sobre o pull request.
Painel direito – Revisores
Esta seção rastreia atribuições e ações dos revisores:
Revisores designados – lista de usuários adicionados como revisores.
Status do revisor – mostra se um revisor está pendente, solicitou alterações ou aprovou.
✏️ Ícone de lápis – permite adicionar ou atualizar revisores.
Se nenhum revisor estiver atribuído, o painel exibe “Nenhum revisor.”
Este painel é essencial para gerenciar e monitorar o fluxo de revisão.
Adicionando revisores
Abra a página de visão geral do pull request.
Localize o Revisores painel à direita.
Clique no ✏️ ícone de lápis para gerenciar os revisores.
Na Modal de revisores, pesquise usuários e clique em Adicionar.
Os revisores selecionados aparecem no topo.
Use o botão preto Adicionar na parte inferior para confirmar.
Os revisores agora verão o PR na fila deles.
Revisando sem revisores atribuídos
Se nenhum revisor for adicionado, você como criador do PR (ou outro usuário com acesso) ainda pode revisar a solicitação.
Uma vez que você revisar o PR, o status é atualizado para “Revisão Solicitada.”
Isso permite que o fluxo de trabalho continue mesmo quando revisores formais não estão atribuídos.
Lidando com conflitos
Quando um PR contém alterações conflitantes com o branch de destino:
Um banner aparece no topo da página Visão Geral mostrando o número de arquivos com conflitos.
O Merge o botão fica desativado até que os conflitos sejam resolvidos.
Clique Resolver conflitos para começar a corrigi-los.
⚠️ Conflitos devem ser resolvidos antes que o PR possa prosseguir.
Solicitando alterações
Os revisores podem solicitar modificações ao PR se encontrarem problemas.
Vá para a Componentes alterados aba.
Revise os componentes listados e as alterações de código.
Clique Solicitar alterações.
O status do PR é atualizado para Alterações Solicitadas.
Isto sinaliza ao autor do PR para atualizar o branch fonte com as correções necessárias.
Aprovando um Pull Request
Se as alterações atenderem aos padrões de qualidade:
Abra o PR e revise as Visão geral e Componentes alterados abas.
Clique Aprovar.
O status do PR é atualizado para Aprovado, e o PR está pronto para mesclar.
Mesclando um Pull Request
Uma vez que um PR foi revisado e validado:
Vá para a página de visão geral do pull request.
Confirme que o branch pode ser mesclado (mensagem de status verde).
Clique no Merge botão no canto superior direito.
As alterações do branch fonte são mescladas no branch de destino.
Exemplo
Um desenvolvedor cria um pull request de FeatureBranch → ReleaseBranch.
Nenhum revisor está designado.
O desenvolvedor clica no ícone de lápis, mas deixa de adicionar revisores.
O desenvolvedor revisa as alterações diretamente, mudando o status para Revisão Solicitada.
O PR mostra um banner de conflito, então os conflitos são resolvidos.
Um revisor clica em Solicitar alterações, atualizando o status para Alterações solicitadas.
Após as correções, o revisor clica em Aprovar.
Finalmente, o desenvolvedor clica em Merge, integrando as alterações no ReleaseBranch.
Melhores práticas
Sempre adicione pelo menos um revisor para responsabilização.
Use o campo de descrição para resumir as principais alterações para os revisores.
Mescle somente quando todos os conflitos estiverem resolvidos e os testes tiverem passado.
Use Solicitar alterações em vez de bloquear silenciosamente — isso mantém o fluxo de trabalho claro.
Evite auto-mesclar sem revisão, a menos que seja uma correção crítica.
Atualizado