Yuki
Blog
ブログ
總之先從 A 開一個 Branch B 出來吧！ 那 A 被 merged 到 dev 後，B 該怎麼辦？ 又如果 A 需要修改，改好才 merged，要對 B 做什麼事情才能繼續開發嗎？
好的，這是在「多人協作」的開發過程中，常見的情境，關鍵字可以搜「git stacked / dependent branches」之類的就有。
該怎麼辦其實很簡單，以下一步步手把手教。
沒錯，先從 A 開一個 Branch B 就對了。
因為 B 的功能依賴 A，當然就得以 A 為起點開一個分支出來，才能延續著做。
# 1. 確定自己是在 A，如果不是，切到 A
git switch branch-a
# 2. (Optional) 只是個習慣，確保 A 是最新版本
git pull origin branch-a
# 3. 從 A 建立並切到 B
git switch -c branch-b
如此一來就能先安心繼續趕工做 B，同事也能依照自己的步調幫你 Code review，皆大歡喜。
狀況① ーー A 無事通過 Review 被 merged 到 dev 之後，B 該怎麼辦？
好的，一旦 A 被合併進主要分支（就假設是 dev 吧），A 的使命其實就完成了。像我現在待的團隊是用 GitLab，還有設定 merged 後就自動把 origin A 砍了呢。
此時 B 的「基底」就不應該再是 A，而該是已經包含了 A 內容的 dev。
所以，需要做的動作是「變基」，把 B 的起點從 A 搬到到最新的 dev 上，沒錯 －－ 就是要用 git rebase 了啦！
# 1. 確定自己是在 dev，如果不是，切到 dev
git switch dev
# 2. 把最新的 dev 拉下來
git pull origin dev
# 3. 切回 B
git switch branch-B
# 4. 執行 rebase 移花接木
git rebase dev
講一下這邊 git rebase dev 的內部運作過程。
雖然說是「移花接木」，但過程是怎麼移、怎麼接的？
來個視覺化理解：
- Rebase 前
---o---o---o (dev)
\
---A1---A2 (branch-a)
\
---B1---B2 (branch-b)
- A 被 merged 進 dev 後
---o---o---o---A1'---A2' (dev)
\
---A1---A2 (branch-a) 這個分支其實已經沒用了
\
---B1---B2 (branch-b) B 的基礎還是舊 commit
- 執行
- 首先
- 再來
- 然後
- 最後
---o---o---o---A1'---A2' (main)
\
---B1'---B2' (branch-B) <- 乾淨！
執行完成後，B 的歷史紀錄會變乾淨，就像是直接從最新的 dev 開出來的一樣。
狀況② ーー A 在 Review 過程中有修改，修改後才 merged，B 該怎麼辦？
其實和上面的處理方式完全一樣
可能會遇到的困難 ーー 衝突
如果在 A 的修改中，動到了你 B 分支也改過的同一行程式碼，rebase 過程會暫停，並提示你哪些檔案有衝突。
這很正常，不用慌張，你就乖乖認命解衝突吧。
蛤？你說不知道怎麼解衝突？那我以後再寫一篇文 w
總結
- 先從 A 開 B 分支。
- 等待 A 合併後，將 B rebase 到 dev，這是標準且乾淨的做法。能確保 B 包含所有最新的程式碼，包括 A 的最終修改，並讓 Git 歷史線圖保持整潔。
- 可以和 review A 分支的同事說一聲，讓他知道你正在基於 A 開發 B，這樣大家互相心裡有數、有個照應，「菠菜法則」有興趣可以了解一下。
- 即使 A 還沒合併，也可以偶爾將 B rebase 到 A 的最新進度上 (
git rebase branch-a)，隨時同步 A 的修改，避免最後差距太大產生巨大衝突。