finishing-a-development-branch

開発ブランチを完了する

概要

統合の選択とチェックアウトの存続期間は別々に扱います。まず検証し、タスクが所有するリソースのみを変更してから、削除または保持したものを確認します。

基本原則： 最新の証拠 -> 承認された統合 -> 所有権を考慮したクリーンアップ -> Git／パスの読み戻し。

開始時に伝えること： どのブランチ／ワークツリーのライフサイクルを終了するのかを説明します。

ステップ 1：環境と所有権の検出

タスクの TaskStartSnapshot と現在のリポジトリ状態を確認します。以下を記録します。

• ルート、HEAD、ブランチ／デタッチ状態、上流との差分、実行中の Git 操作。
• ステージ済み／未ステージ／未追跡のパス、およびタスク所有の差分。
• git worktree list --porcelain。
• ブランチ／ワークツリーの作成者、タスクの所有権、ベースブランチ、クリーンアップのトリガー。

競合、説明のつかないデタッチ状態、検証の失敗、クリーンアップ対象の変更済み／未追跡状態、または不明な所有権がある場合は中止します。main や master という名前からベースを推測しないでください。タスクの記録、リポジトリの権限情報、またはユーザーからの明示的な指示を使用します。自動で stash、reset、clean、pull、rebase、amend、force-push を実行したり、フックを回避したりしないでください。

信頼できるホスト管理のデタッチされたチェックアウトの場合は、リポジトリで承認された管理ワークスペースの契約に従います。ホストとの紐付け、デフォルトの cwd、ルート、HEAD を確認してから、スコープが限定されたローカルコミットとネイティブのハンドオフ経路を使用します。記録にはデタッチ状態の HEAD を記載します。この例外は、デタッチされたチェックアウトを自動的に削除したり、不明な所有権／紐付けを無視したりする権限を与えるものではありません。

タスクで作成したブランチ／ワークツリーがなく、統合も依頼されていない場合は、このワークフローをスキップします。ローカルタスクコミットと Task clean、Repository clean を報告し、マージ／PR の手順を勝手に追加しないでください。

ステップ 2：最新の検証

完了したタスクを証明するために、現在の権威ある情報に基づく最小限のテストセットを実行します。失敗した場合はすべての作業を保持し、原因の調査に戻ります。ブランチが準備完了であると示してはいけません。

ステップ 3：承認された結果を選択する

タスクブランチの処置が実際に必要な場合は、該当する選択肢のみを提示します。

1. 記録されたベースにローカルでマージする。
2. プッシュして PR を作成／更新する。
3. 後で統合できるようブランチを保持する。
4. タスク所有の該当ブランチ／ワークツリーを破棄する。

プッシュ、PR、リモート削除、リリース、強制操作には、ユーザーの明示的な許可が必要です。破棄には、失われるブランチ、ワークツリーのパス、コミット／差分を明記した、最新かつ正確な入力による確認が必要です。一般的な同意だけでは不十分です。

ステップ 4：隠れた変更を加えずに実行する

ローカルマージ

対象のチェックアウトが安全であることを確認し、記録されたベースに切り替えて、暗黙の pull を行わずにマージし、マージ後の結果を再検証します。統合または検証に失敗した場合は、両方の履歴を保持して中止します。

プッシュまたは PR

承認されたタスクブランチのみをプッシュし、概要と最新のテスト証拠を添えて PR を作成／更新します。PR の作成だけではマージの証明にはならず、一時ワークツリーを残す必要もありません。

ブランチの保持

ブランチを保持します。タスクで作成したクリーンな一時ワークツリーは、デフォルトでは削除します。継続的にチェックアウトしておく明示的な必要がある場合のみ保持し、その理由を報告します。

破棄

正確な確認を得た後、指定されたクリーンなタスク所有ワークツリーのみを削除し、その後に指定されたブランチを削除します。どちらかが確認内容と異なる場合は中止し、再度確認を求めます。

ステップ 5：ブランチ削除前に統合を証明する

マージ戦略に合った証拠を使用します。

• マージ／ファストフォワード：タスクの先端が記録されたベースの祖先であることを証明します。
• スカッシュ／リベース：最新の PR マージメタデータに加え、戦略に適したパッチの同等性（リベースされたコミットには git cherry、スカッシュには安定した patch-id または範囲を限定した変更パス／ツリーの比較）を使用します。祖先かどうかだけで判断してはいけません。
• 未マージ／オープン中の PR：破棄が正確に確認されていない限り、ブランチを保持します。

PR が開かれたことや、同じような名前のコミットが存在することだけを理由にブランチを削除してはいけません。

Step 6: 依存関係の順序に沿ったクリーンアップ

タスク所有のリソースがクリーンな場合：

1. 別の安全な登録済みチェックアウトに移動します。現在の作業ディレクトリは削除しないでください。
2. git worktree remove <exact-path> を使って、まずワークツリーを削除／登録解除します。
3. git worktree list --porcelain の出力を再確認します。
4. 指定したパスが存在しなくなったことを確認します。
5. その後に限り、統合済み、または正確に確認済みのブランチを削除します。
6. ブランチ参照、HEAD、リポジトリの状態を再確認します。

通常の手順として --force、グローバルな git worktree prune、ワイルドカードによる削除、またはタスク所有記録にないリソースのクリーンアップを行わないでください。Windows では、ディレクトリがロックされたままでも Git がワークツリーの登録を解除する場合があります。登録状態と解決済みの正確なパスを再確認し、安全な場合に限り、タスク所有であることが証明されたクリーンな残存ディレクトリのみを削除してください。それ以外の場合はそのまま残し、ロックまたはパスについて報告してください。削除範囲を広げないでください。

最終 Git レシート

以下を報告してください。

• 現在のブランチとコミット SHA／メッセージ、またはコミットが存在しない理由
• Task clean: yes|no と Repository clean: yes|no をそれぞれ個別に報告
• 作成、削除、または保持したブランチ／ワークツリーと、その根拠／理由
• 統合の証拠と、残っているユーザー操作

Task clean は、コミットされていないタスク所有の差分が残っていないことを意味します。Repository clean は、ステージ済み、未ステージ、または未追跡のリポジトリ状態が残っていないことを意味します。

これはローカル Git のレシートであり、再確認した証拠を超えて、完了やマージの事実を確定するものではありません。

統合

ブランチ／ワークツリーの統合、または明示的なライフサイクル管理が対象となる場合にのみ呼び出してください。using-git-worktrees および verification-before-completion と組み合わせて使用します。