Revisar e fazer merge de uma PR

Este guia mostra como revisar e fazer merge de uma pull request.

Abrir o ambiente de trabalho da PR

Navegue até Pull requests na barra lateral
Selecione uma PR na lista

Uma PR abre como um ambiente de trabalho com abas, e não como uma página única. Cinco abas abrem por padrão, nesta ordem: Visão geral, Diff, Controle de versão, Chat e Ações (verificações de CI agrupadas por fluxo de trabalho). Revisão — o progresso do pipeline de revisão e, depois, o artefato que ele publicou com sua coluna de achados — deliberadamente não é uma delas: uma PR não tem revisão até alguém pedir uma, então Ask AI a abre. Um terminal, um editor de arquivo único, um code-server incorporado e um navegador dentro do app abrem sob demanda; abas de pré-visualização de implantação são injetadas automaticamente quando uma URL de pré-visualização é detectada na PR. O layout das suas abas é lembrado por PR.

A aba Visão geral traz os metadados da PR (autor, branch, etiquetas, responsáveis, reações, commits, status das verificações) e a linha de ações: atualizar, Revisão, Merge, abrir no IDE e um menu de overflow ⋯.

Ler o diff

Abra a aba Diff para ver o diff inteiro da PR de uma vez, com uma árvore de arquivos para pular entre arquivos.

O botão de configurações na barra de ferramentas do diff alterna entre a visualização dividida (lado a lado) e a unificada, e liga ou desliga a quebra de linha e as ligaduras da fonte de código.
Os cabeçalhos de hunk @@ são substituídos por controles Show N lines / Show end of file, que inserem o contexto ao redor quando você clica.
Pressione j / k para avançar entre arquivos, c para recolher ou expandir o arquivo em foco, t para devolver a barra lateral à árvore de arquivos e ⌘F para pesquisar em todo o diff (Enter / Shift+Enter percorrem as correspondências).
Pressione v para marcar o arquivo em foco como visto, e o cursor avança para o próximo arquivo. No GitHub o estado de visto fica armazenado no host de código, então ele acompanha você entre clientes; GitLab e Bitbucket não têm essa API, então lá ele é lembrado apenas neste dispositivo.

Arrastar com o mouse na área de código seleciona o texto até a coluna exata, e ⌘C copia o código-fonte bruto em vez dos marcadores de diff renderizados.

Deixar comentários em linha

Toque na margem de uma linha de código para abrir um campo de comentário ancorado nessa linha, ou use o botão + no cabeçalho de um arquivo para um comentário no nível do arquivo
Escreva seu comentário em Markdown
Envie

No GitHub e no GitLab o campo de comentário oferece dois envios: Adicionar um único comentário publica imediatamente, e Iniciar uma revisão / Adicionar à revisão enfileira o comentário em uma revisão pendente que sai junto com Aprovar, Solicitar alterações ou Comentário. O Bitbucket não tem agrupamento de revisões pendentes, então lá todo envio é publicado imediatamente. Um envio imediato mostra um estado pendente até o host de código confirmá-lo e então passa para sincronizado. Se o envio falhar, a conversa fica marcada com o erro e oferece uma nova tentativa.

Só o corpo da revisão é um rascunho: ele é salvo no servidor associado a (proprietário, repo, número da PR) um instante depois de você parar de digitar, então ele sobrevive a um recarregamento e acompanha você entre os clientes desktop e web.

Enviar uma revisão

Pressione Revisão na linha de ações da Visão geral (ela fica oculta nas suas próprias PRs e em uma PR fechada ou já mesclada)
Escreva o corpo da revisão. Você pode anexar uma imagem, inserir um emoji ou um GIF e alternar entre escrita e pré-visualização
Pressione Solicitar alterações, Comentário ou Aprovar

O veredito é o botão — não existe um seletor de veredito separado. Depois de Aprovar ou Solicitar alterações, o botão muda de rótulo para Aprovado ou Alterações solicitadas, e o corpo do rascunho é apagado. Um veredito Comentário deixa o botão com o rótulo Revisão.

Fazer merge

O botão Merge aparece quando você tem acesso de escrita e a PR está aberta e não é um rascunho. A cor dele é um sinal de prontidão derivado das aprovações obrigatórias e do estado das verificações (pronto / pendente / bloqueado) — é apenas orientativo. O estado da revisão nunca desativa o botão; é a própria proteção de branch do host de código que aplica as regras.

Pressione Merge para abrir o painel flutuante de merge
Escolha um método de merge: squash, merge commit ou rebase (squash é o padrão). O Bitbucket não tem um merge com rebase de verdade, então o rebase é mapeado para a estratégia fast-forward dele e falha em um branch divergente
Para squash e merge commit, edite o título e a descrição do commit preenchidos previamente. O rebase não aceita nenhum dos dois e oculta os dois campos
Leia o painel de avisos — ele nomeia as verificações com falha e as revisões pendentes, mas não bloqueia você
Pressione o botão de merge no painel flutuante para confirmar

Fazer merge é irreversível: ele envia commits para o host de código, então recebe uma etapa de confirmação em vez de uma entrada na pilha de desfazer. Depois disso, o cache da PR é invalidado, o status dela passa para Mesclado e um evento PullRequestStatusChanged é disparado com o status merged. Esse evento libera o worktree efêmero de “abrir no editor” e inicia dois pipelines predefinidos: Stale repository cleanup, que remove os worktrees obsoletos e as pastas de conversa da PR, e Release notes, que redige uma entrada de changelog.

Entregar a PR aos agentes revisores

O menu de overflow ⋯ da aba Visão geral traz Ask AI, que inicia o pipeline pr_review predefinido para esta PR. Ele só aparece enquanto a PR está aberta. Consulte Usar revisão com IA para saber o que o pipeline faz e como publicar seus achados, e Computação de revisão para o modelo determinístico de coortes e eixos.

Revisar uma PR externa

O Control Center também importa PRs abertas por pessoas fora do app. O fluxo de revisão acima é idêntico. As PRs externas são detectadas pelo serviço de polling de PRs.