結論
| 状況 | ブランチの切り方 |
|---|---|
| AとBが依存しない | main から切る |
| BがAに依存する | A から切る |
パターン①：依存しない場合
状況
main
├─ A（PR中）
└─ B（新規）
・同じ行を触らない
・AのロジックをBで使わない
・Aの変更前提ではない
手順
① A作成
git checkout main
git pull origin main
git checkout -b A
# 作業
git add .
git commit -m "feat: Aの実装"
git push origin A
👉 GitHubで
base: main
compare: A
② Bはmainから切る
git checkout main
git pull origin main
git checkout -b B
# 作業
git add .
git commit -m "feat: Bの実装"
git push origin B
👉 GitHubで
base: main
compare: B
マージ順
AもBも独立しているので、どちらが先でもOK
コンフリクトがなければそのままマージ
パターン②：BがAに依存する場合
状況
main
└─ A（PR中）
└─ B
例：
・AでServiceを追加
・BでそのServiceを使用
・同じ行にdusk属性追加
手順
① Aをmainから作成
git checkout main
git pull origin main
git checkout -b A
# 作業
git add .
git commit -m "feat: Aの実装"
git push origin A
👉 PR
base: main
compare: A
② BをAから作成
git checkout A
git pull origin A
git checkout -b B
# 作業
git add .
git commit -m "feat: Bの実装"
git push origin B
👉 PR
base: A
compare: B
（↑ ここが超重要）
なぜBのbaseをAにするのか？
PRは「baseとの差分」を表示する。
もし B → main にすると
👉 Aの変更も全部差分に出る
レビュー不能になる。
（依存あり）のPRメモ（超重要）
BのPRにはこれを書く：
## 概要
〇〇機能の追加
## 依存関係
このPRは #123（A）に依存しています。
Aがマージ後、baseをmainへ変更予定です。
## 確認方法
Aの変更が前提になります。
🧠 なぜこれが大事？
依存PRでメモがないと：
・差分が分からない
・なぜ動かないのか不明
・どっちを先に見るべきか分からない
③ Aをマージ
GitHubでAをmainへマージ。
その後ローカル更新：
git checkout main
git pull origin main
④ Bをmainに追従させる
git checkout B
git fetch origin
git rebase origin/main
コンフリクトが出たら修正：
git add .
git rebase --continue
完了後：
git push origin B --force