resolve-merge-conflict
[!NOTE] この作業は安い AI Model で済ませたいので、あなたが高価な Model であれば以降の作業は安い Model の SubAgent に移譲してください.
最初にやること
- branch の目的を 1-2 文で確認する
- rebase 先の branch を決める
- さっさと
git fetchとgit rebaseを実行する
手順
-
状態確認
git status --short --branch -
base を更新して rebase 開始
git fetch origin <base> git rebase origin/<base> -
止まったら conflict file を確認
git diff --name-only --diff-filter=U -
簡単な file から解消
- formatter
- import order
- rename / move
- 機械的に両方載せられる変更
-
迷う file だけ 3-way を見る
git show :1:path/to/file git show :2:path/to/file git show :3:path/to/file
:1:base:2:applying commit:3:rebased branch
-
解消したら追加して続行
git add <files> git rebase --continue -
次の conflict が出たら繰り返す
squash merge された親ブランチへの rebase
通常の git rebase では対処できないケースがある。
症状: 親ブランチが squash merge されており、rebase すると親ブランチのコミットが原因のコンフリクトが大量発生する。
原因: squash merge は親ブランチの全コミットを 1 つの新しいコミットに畳む。子ブランチの履歴には元の親コミットが残っているため、git は「まだ取り込まれていない」と判断して再適用しようとする。
対処:
# 1. 親 PR の headRefOid(squash 前の先頭コミット)を取得
old_parent_tip=$(gh pr view <親PRの番号> --json headRefOid --jq .headRefOid)
# 2. ローカルに存在するか確認(なければ fetch)
git cat-file -e "$old_parent_tip" 2>/dev/null || \
git fetch origin $(gh pr view <親PRの番号> --json headRefName --jq .headRefName)
# 3. --onto で「親のコミット以降だけ」を新しい base に乗せ直す
git rebase --onto origin/<新しいbase> "$old_parent_tip"
--onto origin/main <old_parent_tip> の意味:
old_parent_tip..HEADの範囲のコミット(= 自分のコミットだけ)をorigin/mainの上に乗せる
これで親ブランチのコミットは再適用されない。
generated file / lockfile
- source file を先に直す
- generated file は後回し
- lockfile は片方を採って前進し、rebase 後に再生成する
例:
git checkout --ours ui/pnpm-lock.yaml
git add ui/pnpm-lock.yaml
PR を見る条件
最初から見ない。必要なときだけ見る。
- base が曖昧
- branch の目的が commit だけでは読めない
- ユーザー確認前に背景が必要
gh pr view --json number,title,body,url,baseRefName,headRefName
gh pr diff --name-only
ユーザー確認が必要なケース
- どちらの仕様を採るか決めきれない
- API / UI の最終挙動が二者択一
- config / migration / security 影響がある
確認は短く聞く。
`path/to/file` で conflict しています。
branch 側は <change>、base 側は <change> です。
推奨は <resolution> です。これで進めてよいですか?
完了後
git push --force-with-lease origin HEAD
push 後、このブランチに open PR があれば adjust-pr-base skill を実行する。
rebase 先が変わった場合、PR の base branch も古いまま残ることがあるため。
報告すること:
- どこに rebase したか
- conflict をどう解いたか
- ユーザー確認が必要だった件数