git-pr-workflows-git-workflow

ガード付き Git プルリクエストワークフロー

リポジトリポリシーやブランチ保護を迂回することなく、完了した変更をローカルレビューから検証済みのプルリクエストへ移します。

使用する場面

レビュー、テスト、コミット、トピックブランチへのプッシュ、およびプルリクエストの作成が必要な、完了済みの実装作業に使用します。必須のメンテナー専用ワークフローやリリースワークフローがリポジトリに定義されている場合は、代わりにそちらを使用してください。

ポリシーゲート

変更を加える前に:

1. AGENTS.md、コントリビューションガイド、メンテナー向けドキュメント、および関連するネストされた指示を読みます。
2. 現在のブランチ、ワークツリー、リモート、上流ブランチ、および有効なターゲットブランチ保護を確認します。
3. リポジトリネイティブの検証、コミット、PR、マージ、リリースの各コマンドを把握します。
4. 無関係なダーティファイルおよびステージ済みファイルを保持します。

リポジトリポリシーはフラグやユーザーの略記よりも優先されます。トランクベース開発は直接プッシュを意味しません。ターゲットが保護されている場合は、短命なブランチとプルリクエストを使用してください。リポジトリが必須のメンテナースキルやガード付きマージコマンドを定義している場合は、マージおよびリリース操作をそれに引き渡します。agentic-awesome-skills では、antigravity-maintainer-batch-release と npm run merge:batch を使用します。

入力

リクエストとリポジトリからこれらを解決します:

• ターゲットブランチ。デフォルトはリポジトリのデフォルトブランチです。
• 意図する変更ファイルと除外するユーザー作業。
• 必須のテスト、リント、セキュリティ、ビルド、およびドキュメントのチェック。
• ブランチ命名規則とコミットメッセージ規則。
• ドラフトまたはレビュー準備完了の PR 状態。
• 必須のレビュアー、ラベル、Issue リンク、およびマージ方法。

不足している選択が結果を大きく変える場合にのみ確認してください。

ワークフロー

1. 正確な変更を捕捉する

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

スコープ内のすべてのファイルを確認します。ステージ済みファイルまたはダーティファイルを安全に分離できない場合は停止します。

2. 並行してレビューする

サブエージェントが利用可能で承認されている場合は、次の独立した有限のレビューパスを割り当てます:

• 正確性とリグレッションリスク。
• セキュリティ、シークレット、権限、および依存関係のリスク。
• テストカバレッジとリポジトリポリシーへの準拠。

各レビュアーに生の差分とリポジトリの指示を渡します。重複排除、重大度、編集、および最終検証はメインエージェントが担当します。

3. 検証して修復する

リポジトリの対象を絞ったチェックを実行し、その後、必須の PR 前スイートを実行します。チェックが失敗した場合:

1. 原因がソース、ポリシー、環境、またはインフラストラクチャのいずれであるかを特定します。
2. スコープ内のソースまたはポリシーの欠陥のみを修正します。
3. 対象の失敗を再実行します。
4. 必須の完全なスイートを再実行します。

ゲートを弱めたり、スキップされたテストを隠したり、決定論的な失敗をフレークとして扱ったりしないでください。

4. ブランチとコミットを準備する

コミットする前にターゲットをフェッチします。現在保護ブランチまたはデフォルトブランチにいる場合は、変更を加える前にトピックブランチを作成します。

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

意図したパスのみをステージし、リポジトリポリシーに従って焦点を絞った Conventional Commits を作成します。厳格な必須チェックが最新のターゲットを要求する場合は、トピックブランチをリベースまたは更新します。明示的な承認なしに共有ブランチを force push しないでください。

5. プッシュしてプルリクエストを作成する

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

PR 本文には次の内容を正確に含める必要があります:

• 何を変更し、なぜ変更したか。
• 実際に実行したテストと検証。
• 該当する場合は、リスク、デプロイ、ロールバック、および破壊的変更に関する注記。
• 該当する場合は、Issue リンク、スクリーンショット、およびリポジトリのチェックリスト。

保留中の自動レビューやテストを完了としてマークしないでください。

6. リモートの結果を検証する

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

レビューの証拠を現在の完全なヘッド SHA に紐づけます。ヘッドまたはベースが変更された場合は、古い結論を破棄し、影響を受けるチェックを再実行します。

リポジトリのガード付きマージパスを使用します。必須チェック、マージキュー、正確な SHA のアテステーション、またはメンテナーコマンドを、生のマージ API で置き換えないでください。マージ後、ターゲットをフェッチし、要求されたリモート、CI、デプロイ、またはリリースの状態を検証します。

停止条件

PR が意図したヘッドに存在し、必須チェックがグリーンであるか正確に 1 つのブロッカーがあり、レビューの証拠が最新であり、無関係なユーザーの作業が保持されており、要求されたガード付きマージまたはデプロイが検証済みである時点で終了します。

制限事項

• このワークフローは、ブランチ保護、必須レビュー、リポジトリの権限、または不足している認証情報をバイパスすることはできません。
• ユーザーの要求およびリポジトリのポリシーを超えた破壊的なクリーンアップ、強制プッシュ、マージ、デプロイ、またはリリースを承認するものではありません。
• 未解決の環境またはインフラストラクチャの障害は明示的に保ち続けてください。証拠なしにそれらをソースの変更に変換しないでください。