pull

プル

ワークフロー

1. マージする前に、git のステータスがクリーンであることを確認するか、変更をコミットまたは退避します。
2. rerere がローカルで有効になっていることを確認します。
   • git config rerere.enabled true
   • git config rerere.autoupdate true
3. リモートとブランチを確認します。
   • origin リモートが存在することを確認します。
   • 現在のブランチがマージを受け入れるブランチであることを確認します。
4. 最新の参照を取得します。
   • git fetch origin
5. 先にリモートのフィーチャーブランチを同期します。
   • 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 を使って、ファイル単位で意図を確認できるよう、ベースと ours／theirs を比較します。
  • merge.conflictstyle=zdiff3 を使うと、競合マーカーには次の内容が含まれます。
    • <<<<<<< は ours、||||||| は base、======= は区切り、>>>>>>> は theirs を示します。
    • 競合範囲の先頭と末尾付近で一致する行は除外されるため、異なる部分の中心に注目します。
  • 両方の変更の意図をまとめ、意味的に正しい結果を判断してから編集します。
    • 各側が何を実現しようとしているのか（バグ修正、リファクタリング、名前変更、動作変更）を明確にします。
    • 共通の目的があるか、一方が他方に取って代わるかを特定します。
    • まず最終的な動作を決め、その決定に合うようにコードを作成します。
    • 競合から意図的な変更であることが明らかな場合を除き、不変条件、API コントラクト、ユーザーに見える動作を維持することを優先します。
  • どちらを選ぶか決める前にファイルを開き、両側の意図を理解します。
• 最小限の編集で意図を維持することを優先します。
  • ブランチの目的に沿って動作を一貫させます。
  • 意図しない削除や、明示されない動作変更を避けます。
• ファイルを1つずつ解決し、論理的なまとまりごとにテストを再実行します。
• どちらか一方が全面的に優先されると確信できる場合に限り、ours/theirs を使います。
• 複雑な競合の場合は、関連するファイルや定義を検索して、コードベースの他の箇所と整合させます。
• 生成ファイルの場合は、生成されていないファイルの競合を先に解決してから再生成します。
  • 生成物を編集する前に、ソースファイルと手書きのロジックを解決することを優先します。
  • 生成ファイルを作成した CLI／ツールのコマンドを実行してクリーンな状態で再生成し、その後に再生成された出力をステージします。
• 意図が不明確なインポートの競合の場合は、まず両側を受け入れます。
  • すべての候補のインポートを一時的に残し、マージを完了してから、lint／型チェックを実行して、未使用または不適切なインポートを安全に削除します。
• 解決後に、競合マーカーが残っていないことを確認します。
  • git diff --check
• 判断に迷う場合は、前提を記録し、マージを確定する前に確認を求めます。

ユーザーへの確認が必要な場合（最小限にとどめる）

安全で元に戻せる代替手段がない場合を除き、入力を求めないでください。最善を尽くして判断し、その理由を記録して作業を進めてください。

次の場合に限り、ユーザーに確認してください。

• 適切な解決方法が、コード、テスト、または関連ドキュメントから推測できない製品の意図や動作に依存する場合。
• 競合がユーザーに見える契約、API の仕様、または移行に関わり、誤った選択によって外部の利用者に影響が及ぶ可能性がある場合。
• 技術的な妥当性が同等で、明確な手がかりもない、相互に両立しない 2 つの設計から選ぶ必要がある場合。
• マージによってデータ損失、スキーマ変更、または不可逆な副作用が発生し、明らかに安全な既定の選択肢がない場合。
• ブランチが意図した対象ではない場合、またはリモート名やブランチ名が存在せず、ローカルで特定できない場合。

それ以外の場合は、マージを進め、判断の理由をメモに簡潔に記載し、明確でレビュー可能なコミット履歴を残してください。