pull

name	pull
description	最新の origin/main を現在のローカルブランチに pull し、マージコンフリクトを 解決する（別名 update-branch）。Codex が feature ブランチを origin と同期し、 rebase ではなく merge ベースの更新を行い、コンフリクト解決のベストプラクティス に従う必要があるときに使用する。

Pull

ワークフロー

1. git status がクリーンであることを確認するか、マージ前に変更をコミット／stash する。
2. ローカルで rerere が有効になっていることを確認する:
   • git config rerere.enabled true
   • git config rerere.autoupdate true
3. リモートとブランチを確認する:
   • origin リモートが存在することを確認する。
   • 現在のブランチがマージを受け取るブランチであることを確認する。
4. 最新の ref を fetch する:
   • git fetch origin
5. まずリモートの feature ブランチを同期する:
   • git pull --ff-only origin $(git branch --show-current)
   • これは origin/main をマージする前に、リモートで行われたブランチ更新（例: GitHub の自動コミット）を取り込む。
6. 順番にマージする:
   • より明確なコンフリクトコンテキストを得るため git -c merge.conflictstyle=zdiff3 merge origin/main を優先する。
7. コンフリクトが現れたら解決し（下記のコンフリクトガイダンスを参照）、その後:
   • git add <files>
   • git commit（マージが一時停止している場合は git merge --continue）
8. プロジェクトのチェックで検証する（AGENTS.md のリポジトリポリシーに従う）。
9. マージをサマリする:
   • 最も困難だったコンフリクト／ファイルとそれをどう解決したかを伝える。
   • 仮定やフォローアップを記録する。

コンフリクト解決ガイダンス（ベストプラクティス）

• 編集前にコンテキストを検査する:
  • git status でコンフリクトしたファイルを一覧表示する。
  • git diff または git diff --merge でコンフリクトハンクを見る。
  • ファイルレベルの意図を見るため、git diff :1:path/to/file :2:path/to/file と git diff :1:path/to/file :3:path/to/file で base と ours/theirs を比較する。
  • merge.conflictstyle=zdiff3 ではコンフリクトマーカーに以下が含まれる:
    • <<<<<<< ours、||||||| base、======= 区切り、>>>>>>> theirs。
    • 開始／終了付近の一致行はコンフリクト領域から除去されるため、異なるコア部分に集中する。
  • 両側の変更の意図をサマリし、意味的に正しい結果を決定してから編集する:
    • 各側が達成しようとしていること（バグ修正、リファクタ、リネーム、挙動変更）を述べる。
    • 共有のゴールがあるか、一方が他方を上書きするかを特定する。
    • まず最終的な挙動を決定し、その後その決定に合わせてコードを作る。
    • コンフリクトが意図的な変更を明確に示していない限り、不変条件、API 契約、ユーザー可視の挙動の保持を優先する。
  • 解決方法を選ぶ前に、ファイルを開いて両側の意図を理解する。
• 最小で意図を保つ編集を優先する:
  • ブランチの目的と挙動を整合させる。
  • 偶発的な削除や暗黙の挙動変更を避ける。
• 一度に 1 ファイルずつ解決し、論理的なバッチごとにテストを再実行する。
• 一方が完全に勝つべきと確信できる場合のみ ours/theirs を使う。
• 複雑なコンフリクトでは、コードベースの他の部分と整合させるために関連ファイルや定義を検索する。
• 生成ファイルの場合、まず非生成のコンフリクトを解決し、その後再生成する:
  • 生成された成果物に触れる前に、ソースファイルと手書きロジックの解決を優先する。
  • 生成ファイルを生成した CLI／ツールコマンドを実行してきれいに作り直し、再生成された出力をステージする。
• 意図が不明確な import コンフリクトの場合、まず両側を受け入れる:
  • すべての候補 import を一時的に保持し、マージを完了し、その後 lint／type チェックを実行して未使用や不正な import を安全に削除する。
• 解決後、コンフリクトマーカーが残っていないことを確認する:
  • git diff --check
• 不確かなときは仮定を記録し、マージを最終化する前に確認を求める。

いつユーザーに確認するか（最小限に）

安全で可逆的な代替手段がない場合を除き、入力を求めない。ベストエフォートで決定し、根拠を記録して進めることを優先する。

ユーザーに確認するのは以下の場合のみ:

• 正しい解決が、コード・テスト・近接するドキュメントから推論できないプロダクト意図や挙動に依存する場合。
• コンフリクトがユーザー可視の契約、API サーフェス、またはマイグレーションをまたぐ場合で、誤った選択が外部消費者を壊す可能性がある場合。
• コンフリクトが、技術的な利点が同等で明確なローカルシグナルがない、相互排他的な 2 つのデザインの選択を要求する場合。
• マージがデータ損失、スキーマ変更、または明らかな安全なデフォルトのない不可逆な副作用を導入する場合。
• ブランチが意図したターゲットでない、またはリモート／ブランチ名が存在せずローカルで決定できない場合。

それ以外の場合は、マージを進め、ノートで決定を簡潔に説明し、明確でレビュー可能なコミット履歴を残す。