pull

name	pull
description	現在のローカルブランチへ最新の `origin/main` を取り込み、マージ競合を 解決する（いわゆる update-branch）。feature branch を origin と同期し、 rebase ではなく merge で更新し、競合解決のベストプラクティスに沿って 進める必要があるときに使う。

Pull

ワークフロー

1. git status がクリーンか確認し、そうでなければマージ前にコミットまたはstash する。
2. rerere がローカルで有効か確認する。
   • git config rerere.enabled true
   • git config rerere.autoupdate true
3. remote と branch を確認する。
   • origin remote が存在すること。
   • 現在のブランチがマージ先のブランチであること。
4. 最新の ref を取得する。
   • git fetch origin
5. 先に remote 側の feature branch を同期する。
   • git pull --ff-only origin $(git branch --show-current)
   • これにより、origin/main を取り込む前に、remote で加わった branch 更新（例: 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 で競合 hunk を確認する。
  • 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 / 型検査で未使用や誤った import を安全に削る。
• 解決後は競合マーカーが残っていないことを確認する。
  • git diff --check
• 判断に迷う場合は、仮定を明記し、マージ確定前に確認を取る。

ユーザー確認が必要な場面（最小限にする）

安全で可逆な代替がない場合を除き、入力は求めない。まずは合理的な判断を行い、理由を記録して先へ進むことを優先する。

ユーザーに聞くのは次の場合だけ。

• 正しい解決が、コード・テスト・近傍ドキュメントからは読み取れないプロダクト意図や挙動に依存する。
• 競合が、ユーザーに見える契約、API 面、マイグレーションをまたいでおり、誤ると外部利用者を壊す可能性がある。
• 競合解決が、技術的には同等だが両立しない 2 案の選択を要求し、ローカルからは優劣が判断できない。
• マージによって、明確な安全策なしにデータ損失、スキーマ変更、不可逆な副作用が入る。
• 現在ブランチが意図した対象ではない、または remote / branch 名が存在せず、ローカル情報だけでは特定できない。

それ以外はマージを進め、判断理由を短くメモし、レビューしやすい履歴を残す。