Yuki

難道是…叫同事立刻馬上 code review and merge？

欸豆、也不是不行，但分享更好的做法給你。

這是在「多人協作」的開發過程中，常遇到的情境。該怎麼辦很簡單，以下一步步手把手教。

總之先從 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，彼此進度不受影響。可喜可賀。

Q1：A 無事被 merged 到 dev 之後，能繼續在 B 開發嗎？

一旦 A 被合併進主要分支（在此就假設是 dev），A 的使命就完成了。像我現在待的團隊還有設定 merged 後，遠端倉庫會自動把 origin A 砍了。此時 B 的「基底」就不應該再是 A，而該是已經包含了 A 內容的最新 dev。

所以，需要做的是「變基」，把 B 的起點從 A 搬到到最新的 dev 上，沒錯，就是要用 git rebase 了。

# 1. 開發中的 B 進度都先 commit 起來或 stash 收好，然後切到 dev
git switch dev

# 2. 把最新的 dev 拉下來
git pull origin dev

# 3. 切回 B
git switch branch-B

# 4. 執行 rebase 移花接木
git rebase dev

這是標準且乾淨的做法，B 就如同從最新的 dev 開出來的一樣，繼續安心的在 B 進行開發就好。

Q2：A 在 code review 過程中要來回修改，改完才被 merged，需要對 B 做什麼事情嗎？

不論 A 在合併前發生了多少次修改，只要 A 最終被合併了，那處理方式就和上面的 Q1 一模模一樣樣。

於是講一下這邊 git rebase dev 的運作過程。

雖然說是「移花接木」，但過程是怎麼移、怎麼接的？來個視覺化理解：

• Rebase 前（B 建立在 A 之上）

---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 的根基還在沒用的 A 上

• 執行 rebase 後，歷史線圖會變這樣

---o---o---o---A1'---A2' (dev)
                           \
                            ---B1'---B2' (branch-B) // 乾淨！

甚至能放心把 origin A 跟 local A 都給砍了。

如果遇到衝突？

若 A 在 code review 的來回修改中，動到了 B 也改過的同一處程式碼，rebase 過程會暫停，並提示你哪些檔案需要「解衝突」，解完才能完成 rebase。這很正常，不用慌張，你就乖乖認命解衝突吧。

如果真的很怕衝突，在等候 A 合併時，可以偶爾將 B rebase 到 A（git rebase branch-a），隨時同步 A 的最新進度，加減降低最後產生巨大衝突的風險。

蛤？你說不知道怎麼解衝突？那我以後再寫一篇文。

總結

1. 先從 A 開出 branch B。
2. 待 A 合併後，將 B rebase dev。