Fluxo de Trabalho de Pull Request Protegido do Git

Mova alterações concluídas da revisão local para um pull request verificado sem contornar a política do repositório ou a proteção de branch.

Quando Usar

Use para trabalho de implementação concluído que deve ser revisado, testado, commitado, enviado para um branch de tópico e aberto como um pull request. Use o fluxo de trabalho dedicado de mantenedor ou de lançamento do repositório em vez disso, quando um for obrigatório.

Portão de Política

Antes da mutação:

1. Leia AGENTS.md, orientações de contribuição, documentação do mantenedor e instruções aninhadas relevantes.
2. Inspecione o branch atual, a árvore de trabalho, os remotos, o upstream e a proteção efetiva do branch de destino.
3. Descubra os comandos nativos do repositório para validação, commit, PR, merge e lançamento.
4. Preserve arquivos sujos e preparados não relacionados.

A política do repositório prevalece sobre flags e atalhos do usuário. O desenvolvimento baseado em trunk não implica um push direto: quando o destino é protegido, use um branch de curta duração e um pull request. Se um repositório definir uma habilidade de mantenedor obrigatória ou um comando de merge protegido, passe as ações de merge e lançamento para ele. Em agentic-awesome-skills, use antigravity-maintainer-batch-release e npm run merge:batch.

Entradas

Resolva estas a partir da solicitação e do repositório:

• branch de destino, com padrão para o branch padrão do repositório;
• arquivos alterados pretendidos e trabalho do usuário excluído;
• verificações de teste, lint, segurança, build e documentação necessárias;
• convenções de nomenclatura de branch e mensagens de commit;
• estado do PR como rascunho ou pronto para revisão;
• revisores necessários, rótulos, links de issues e método de merge.

Pergunte apenas quando uma escolha ausente alterar o resultado materialmente.

Fluxo de Trabalho

1. Capture a alteração exata

git status --short --branch
git diff --stat
git diff --cached --stat
git branch --show-current
git remote -v

Confirme todos os arquivos no escopo. Pare se arquivos preparados ou sujos não puderem ser separados com segurança.

2. Revise em paralelo

Quando subagentes estiverem disponíveis e autorizados, atribua passes independentes e limitados para:

• risco de correção e regressão;
• risco de segurança, segredos, permissões e dependências;
• cobertura de teste e conformidade com a política do repositório.

Dê a cada revisor o diff bruto e as instruções do repositório. Mantenha o agente principal responsável pela deduplicação, severidade, edições e verificação final.

3. Valide e repare

Execute as verificações direcionadas do repositório, em seguida, sua suíte pré-PR obrigatória. Se uma verificação falhar:

1. identifique se a causa é código-fonte, política, ambiente ou infraestrutura;
2. corrija apenas defeitos de código-fonte ou política no escopo;
3. reexecute a falha direcionada;
4. reexecute a suíte obrigatória completa.

Não enfraqueça portões, oculte testes pulados ou trate falhas determinísticas como instáveis.

4. Prepare o branch e o commit

Busque o destino antes de commitar. Se estiver atualmente em um branch protegido/padrão, crie um branch de tópico antes da mutação.

git fetch origin <target-branch>
git switch -c <topic-branch> origin/<target-branch>
git status --short --branch

Prepare apenas os caminhos pretendidos e crie commits convencionais focados de acordo com a política do repositório. Rebase ou atualize o branch de tópico quando verificações obrigatórias rigorosas exigirem o destino mais recente; nunca force um branch compartilhado sem autorização explícita.

5. Envie e crie o pull request

git push -u origin <topic-branch>
gh pr create --base <target-branch> --head <topic-branch> \
  --title "<conventional title>" --body-file <body-file>

O corpo do PR deve incluir verdadeiramente:

• o que mudou e por quê;
• testes e validações realmente executados;
• notas de risco, implantação, rollback e quebra de compatibilidade quando aplicável;
• links de issues, capturas de tela e checklists do repositório quando aplicável.

Nunca marque uma revisão ou teste automatizado pendente como concluído.

6. Verifique o resultado remoto

gh pr view <pr-number> --json headRefOid,baseRefOid,mergeable,mergeStateStatus,url
gh pr checks <pr-number>

Vincule a evidência de revisão ao SHA do head completo atual. Se o head ou a base mudarem, descarte conclusões desatualizadas e reexecute as verificações afetadas.

Use o caminho de merge protegido do repositório. Não substitua verificações obrigatórias, filas de merge, atestações de SHA exato ou comandos de mantenedor por uma API de merge bruta. Após o merge, busque o destino e verifique o estado de implantação, CI, lançamento ou remoto solicitado.

Condição de Parada

…