Rever e fazer merge de uma PR

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

Abrir a bancada de trabalho da PR

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

Uma PR abre-se como uma bancada de trabalho com separadores, não como uma página única. Cinco separadores abrem-se por predefinição, nesta ordem: Visão geral, Diff, Controlo de código-fonte, Chat e Ações (verificações de CI agrupadas por fluxo de trabalho). Revisão — o progresso do pipeline de revisão e, em seguida, o artefacto que publicou, com o seu painel de constatações — não é deliberadamente um deles: uma PR não tem revisão até alguém pedir uma, por isso é o Ask AI que a abre. Um terminal, um editor de ficheiro único, um code-server incorporado e um navegador dentro da aplicação abrem-se a pedido; os separadores de pré-visualização de implementação são injetados automaticamente quando é detetado um URL de pré-visualização na PR. A disposição dos seus separadores é memorizada por PR.

O separador Visão geral contém os metadados da PR (autor, branch, etiquetas, responsáveis, reações, commits, estado 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 o separador Diff para ver o diff completo da PR de uma só vez, com uma árvore de ficheiros para saltar entre ficheiros.

O botão de definições da barra de ferramentas do diff alterna entre a vista dividida (lado a lado) e a unificada, e ativa ou desativa a quebra de linhas e as ligaduras da fonte de código.
Os cabeçalhos de hunk @@ são substituídos por controlos Show N lines / Show end of file, que inserem o contexto circundante ao clique.
Prima j / k para avançar entre ficheiros, c para recolher ou expandir o ficheiro em foco, t para devolver a barra lateral à árvore de ficheiros e ⌘F para pesquisar em todo o diff (Enter / Shift+Enter percorrem as correspondências).
Prima v para marcar o ficheiro em foco como visto, e o cursor avança para o ficheiro seguinte. No GitHub, o estado «visto» é guardado na forge, pelo que o acompanha entre clientes; o GitLab e o Bitbucket não têm essa API, pelo que aí só fica memorizado neste dispositivo.

Arrastar o rato na área de código seleciona o texto até à coluna exata e ⌘C copia o código-fonte em 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 compositor ancorado a essa linha, ou use o botão + no cabeçalho de um ficheiro para um comentário ao nível do ficheiro
Escreva os seus comentários em Markdown
Envie

No GitHub e no GitLab, o compositor oferece dois envios: Adicionar um único comentário publica de imediato, e Iniciar uma revisão / Adicionar à revisão coloca o comentário numa revisão pendente, que é submetida com Aprovar, Solicitar alterações ou Comentar. O Bitbucket não agrupa revisões pendentes, pelo que aí cada envio é publicado de imediato. Um envio imediato mostra um estado pendente até a forge o confirmar, e passa depois a sincronizado. Se o envio falhar, o comentário é marcado com o erro e oferece uma nova tentativa.

Só o corpo da revisão é um rascunho: é guardado no servidor associado a (proprietário, repo, número da PR) um momento depois de parar de escrever, pelo que sobrevive a uma recarga e o acompanha entre os clientes de computador e web.

Submeter uma revisão

Prima Revisão na linha de ações da Visão geral (está oculto nas suas próprias PRs e numa PR fechada ou fundida)
Escreva o corpo da revisão. Pode anexar uma imagem, inserir um emoji ou um GIF e alternar entre a escrita e a pré-visualização
Prima Solicitar alterações, Comentar ou Aprovar

O veredicto é o botão — não há um seletor de veredicto 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 é limpo. Um veredicto Comentar deixa o botão com o rótulo Revisão.

Fazer merge

O botão Merge aparece quando tem acesso de escrita e a PR está aberta e não é um rascunho. A sua cor é um sinal de prontidão derivado das aprovações exigidas e do estado das verificações (pronto / pendente / bloqueado) — é meramente indicativo. O botão nunca é desativado pelo estado da revisão; é a proteção de branch da própria forge que aplica as regras.

Prima Merge para abrir o painel de merge
Escolha um método de merge: squash, merge commit ou rebase (o squash é a predefinição). O Bitbucket não tem um merge por rebase verdadeiro, pelo que o rebase é mapeado para a sua estratégia fast-forward e falha num branch divergente
No caso do squash e do merge commit, edite o título e a descrição do commit pré-preenchidos. O rebase não usa nenhum dos dois e oculta ambos os campos
Leia o painel de avisos — nomeia as verificações que falharam e as revisões pendentes, mas não o bloqueia
Prima o botão de merge no painel para confirmar

Fazer merge é irreversível: envia commits para a forge, pelo que tem um passo de confirmação em vez de uma entrada de desfazer. Depois disso, a cache da PR é invalidada, o seu estado passa a Mesclado e é disparado um evento PullRequestStatusChanged com o estado merged. Esse evento liberta o worktree efémero «abrir no editor» e inicia dois pipelines predefinidos: Stale repository cleanup, que remove os worktrees e as pastas de conversa obsoletos da PR, e Release notes, que redige uma entrada de changelog.

Entregar a PR a agentes revisores

O menu de overflow ⋯ do separador Visão geral contém Ask AI, que inicia o pipeline pr_review predefinido para esta PR. Só aparece enquanto a PR está aberta. Consulte Usar revisão com IA para saber o que o pipeline faz e como publicar as suas constatações, e Computação de revisão para o modelo determinístico de coortes e eixos.

Rever uma PR externa

O Control Center também importa PRs abertas por pessoas fora da aplicação. O fluxo de revisão acima é idêntico. As PRs externas são detetadas pelo serviço de sondagem de PRs.