Reveja a sua primeira pull request

O que vai construir

No final deste tutorial, terá:

• Aberto uma pull request na bancada de trabalho de PR do Control Center
• Lido o respetivo diff e deixado um comentário em linha
• Submetido um veredicto de revisão
• Feito merge da PR

Pré-requisitos: Despache o seu primeiro agente concluído e uma pull request aberta num repo registado neste espaço de trabalho. Para os passos de revisão, escolha uma PR que não tenha aberto — o botão Revisão fica oculto nas suas próprias PRs. O merge continua a funcionar numa PR da sua autoria.

Passo 1: Abrir a pull request

1. Clique em Pull requests na barra lateral
2. Encontre a sua PR e clique nela

Ponto de verificação: a PR abre como uma bancada de trabalho com separadores — Visão geral, Diff, Controlo de versão, Chat, Ações — focada em Visão geral: o título e as ações, a descrição e a cronologia de atividade e uma barra lateral com o estado, os revisores, os responsáveis, as verificações e os ficheiros alterados. Clicar num ficheiro ali salta diretamente para ele no separador Diff. O separador Revisão de PR só abre quando alguém pede uma revisão com IA.

Fila vazia com um pedido “ligar o GitHub”

Esse estado significa que o servidor não tem nenhum token do GitHub — o seu cliente nunca tem nenhum. Defina um em Definições → Espaço de trabalho → Perfil e identidade → Hospedagem de código e, em seguida, atualize a lista.

Passo 2: Ler o diff

Abra o separador Diff. Uma árvore de ficheiros recolhível fica à esquerda, e a faixa acima do diff traz um seletor de intervalo de commits — restrinja o diff a um único commit ou a um intervalo deles — além da contagem de ficheiros e das adições e eliminações acumuladas.

O botão de definições na barra de ferramentas do diff controla a forma como este é apresentado:

• Vista Dividida ou Unificada
• Quebrar linhas ou deslocar as linhas longas
• Ligaduras da fonte de código

Marque um ficheiro como visto para acompanhar o seu progresso num diff grande. A navegação por teclado está em Atalhos de teclado.

Passo 3: Deixar um comentário em linha

1. Passe o cursor sobre uma linha no diff — surge uma pequena pastilha + na margem
2. Clique nela para comentar nessa linha, ou arraste-a primeiro na vertical para selecionar um intervalo
3. Escreva o seu comentário. O campo de comentário oferece duas formas de envio:
   • Iniciar uma revisão (ou Adicionar à revisão, se já estiver uma revisão em curso) coloca o comentário em fila. A conversa mostra Revisão pendente até submeter um veredicto no passo 4.
   • Adicionar um único comentário publica-o no GitHub de imediato. A conversa mostra A publicar…, depois Sincronizado, e oferece uma nova tentativa se a publicação falhar.

Para este tutorial, use Iniciar uma revisão, para que o comentário saia juntamente com o veredicto.

Um comentário em fila ainda não está no GitHub

Iniciar uma revisão / Adicionar à revisão mantêm o comentário localmente até submeter um veredicto. Só Adicionar um único comentário publica de imediato. O corpo da revisão que escreve no passo 4 é um rascunho separado.

Passo 4: Submeter uma revisão

1. Clique em Revisão na linha de ações da Visão geral — o mesmo botão também se encontra na barra de ferramentas do separador Diff. Fica oculto nas PRs da sua autoria e numa PR fechada ou já fundida.
2. Escreva um resumo no campo de comentário. É guardado automaticamente como rascunho, pelo que pode fechar a sobreposição e voltar mais tarde.
3. Escolha um veredicto:
   • Solicitar alterações
   • Comentar
   • Aprovar

O veredicto é o botão. Depois de Aprovar ou Solicitar alterações, o botão muda o rótulo para Aprovado ou Alterações solicitadas. Um veredicto Comentar deixa-o com o rótulo Revisão.

Ponto de verificação: o botão apresenta “Aprovado” ou “Alterações solicitadas” se tiver escolhido uma dessas duas opções.

Passo 5: Fazer merge

O botão Merge está presente sempre que o GitHub indica que a PR pode ser fundida — não depende da sua própria aprovação. A sua cor indica a prontidão, e não a permissão: primária quando as aprovações obrigatórias e as verificações estão verdes, secundária enquanto uma verificação ainda está em execução, destrutiva quando um revisor solicitado não aprovou ou uma verificação está a falhar.

1. Clique em Merge
2. Escolha um método: Squash and merge, Create a merge commit ou Rebase and merge
3. Nos dois primeiros, edite o título e a mensagem do commit preenchidos previamente
4. Confirme

Quaisquer problemas pendentes — “Verificações com falha”, “Some reviews are pending” — são apresentados no painel flutuante antes de confirmar.

Fazer merge é irreversível

Fazer merge envia commits para o GitHub. Nunca entra na pilha de anulação do Control Center e não pode ser desfeito a partir daqui.

Depois do merge, é disparado um evento de domínio PrMerged; as análises e as notificações consomem-no. Consulte Eventos de domínio para saber o que mais o escuta.

Rever com IA

O Control Center pode colocar um pipeline de revisores numa PR aberta, mas só quando o pede: o modelo pr_review tem um disparador manual e nada mais.

1. Abra o menu de overflow na linha de ações da Visão geral e escolha Ask AI. O Control Center inicia a execução e abre o separador Revisão de PR, para que possa acompanhar o trabalho dos especialistas.
2. Os agentes revisores registam as suas constatações como nós de revisão no espaço da PR; um passo final consolida-as num único relatório.

O pipeline não publica deliberadamente no GitHub — termina depois de consolidar. A publicação é um passo à parte, que tem de dar por si, com o botão Publicar no GitHub no separador Revisão de PR. Consulte Usar revisão com IA.

Resumo

Abriu uma PR na bancada de trabalho, leu o diff com realce de sintaxe, deixou um comentário em linha, submeteu um veredicto e fez merge — sem sair da aplicação.

A seguir: Crie o seu primeiro pipeline para automatizar fluxos de trabalho com várias etapas.