| name | merge-conflict-resolution |
| description | マージでコンフリクトが発生した時に従う解決フロー。意図の取りこぼしやlintエラーを防ぐ |
| user-invocable | true |
マージコンフリクト解決フロー
マージ時にコンフリクトが発生した場合、このフローに従って解決する。
背景
コンフリクト解決で起きやすい問題:
- 片方の変更意図を取りこぼす(フィールドテーブルの消失など)
- lint/format エラーを見落としたまま解決済みにする
- 解決後に別コミットで修正が必要になり、履歴が汚れる
解決手順
Step 1: コンフリクト元の特定
コンフリクトしたファイルごとに、両サイドの変更元コミットを特定する。
git diff --name-only --diff-filter=U
git log --oneline main -- <conflicted-file>
git log --oneline <feature-branch> -- <conflicted-file>
Step 2: 両サイドの変更意図を把握
各コンフリクト元コミットについて以下を確認する:
- コミットメッセージから変更の目的を読み取る
git show <commit> -- <file> で該当ファイルの diff を確認する
- 両サイドがそれぞれ何を追加・変更したかをリストアップする
チェックリスト:
Step 3: 解決方針を決定
以下の判断基準で解決する:
| ケース | 方針 |
|---|
| 両サイドが同じ箇所を異なる内容に変更 | どちらが最新/正確かを判断し、不足分を補完 |
| 片方が追加、もう片方も別の追加 | 両方の追加を統合 |
| 片方が削除、もう片方が変更 | 変更側の意図を確認し、削除が妥当か判断 |
重要: 採用しなかった側の変更に含まれる情報(テーブル、説明文、フィールド等)が失われていないか確認する。
Step 4: コンフリクト解決の実施
- ファイルを編集してコンフリクトマーカーを除去
- 解決結果が Step 2 で把握した両サイドの意図をすべて反映しているか確認
Step 5: 解決後の検証(コミット前に必ず実施)
マージコミットを作成する前に、以下を全て実行する:
pnpm lint
pnpm format
git add -u
pnpm test
lint/format/test のいずれかが失敗した場合:
- 修正してからマージコミットに含める
- 別コミットにしない(履歴を汚さない)
Step 6: マージコミットの作成
全検証を通過してからコミットする:
git commit --no-edit
Step 7: 解決内容の報告
ユーザーに以下を報告する:
- コンフリクトの原因(どのコミット同士がぶつかったか)
- 解決方針(どちら側を採用したか、統合したか)
- 採用しなかった側の情報で失われたものがないか
- lint/test の結果
やってはいけないこと
- コンフリクト元のコミット内容を確認せずに解決する
- lint/format/test を実行せずにマージコミットを作成する
- コンフリクト解決の修正を別コミットに分ける
- 片方の変更を丸ごと捨てて、もう片方だけを採用する(意図の確認なしに)