選擇合併方向

Question

考慮一個簡單的源代碼控制佈局，其中一個trunk表示將來發布的版本，一個分支代表當前正在生產的版本。

當發現需要在兩個分支中修復的錯誤時，是否應該首先對樹幹進行更改，然後合併到分支，或者首先將分支合併到樹枝？通常情況下，我已經先在主幹中修復了這個修復，然後再向下合併，但這樣會增加風險，導致未來的新功能意外合併。你的經驗最適合什麼？

Answer 1

這兩個選項都很好。它真的取決於它在每個案例基礎上最有意義的地方。

您的痛苦情景還可能包括修復一個分支中的錯誤，並將其合併到其他幾個分支。

較老的源代碼管理工具中的一個更大的問題是記住哪些「補丁」應用在哪裏。

許多較新的scm包實現了與GUID或其他唯一標識符的合併，使合併跟蹤更容易。

在顛覆他們引入合併跟蹤之前，它曾經有意義爲合併提供標準化的簽入格式，以確保您可以輕鬆地跟蹤跨分支的合併。

Answer 2

如果錯誤修復是在它自己的檢查中（這通常是您想要執行的操作），那麼與錯誤修復一起合併新功能的風險相對較小 - 只需選擇該單一檢查作爲修訂合併。

我看到合併來自樹幹分支的錯誤修正更大的風險，即您可以忘記進行合併。目前，一切都看起來很好 - 你從分支構建的發佈版本有修正。只有在很久以後，您纔會發現該錯誤仍在樹幹中，因爲您忘記了合併。

由於這個原因，我寧願修復樹幹，然後合併到分支。

Answer 3

我總是強制執行一個策略，首先修復trunk中的錯誤，然後將其合併到release分支。

我選擇這個是因爲任何必須發佈的更改都需要在進入發佈分支之前進行審查，測試和驗證。發佈分支是原始代碼的副本，因此只有經過審覈，測試和驗證的更改才能投入使用。

Answer 4

在記錄完整合並歷史記錄的系統中（例如基於DAG的系統，如Git，Mercurial和其他系統），可能最有意義的是在最老的地方分支的分支上開發功能和修復，特定的變化。 這使得將完成的分支合併到所有目標分支變得更加容易。

您剛從development開始。

--o--o--o development 

最終，您決定內容已準備好可以使用。您製作production分支。工作繼續進行development，但該工作尚不適用於production（這意味着您不應該嘗試合併development到production）。

--o--o--o--o   production 
      \ 
      o--o--o development 

發現了一個錯誤，它需要在兩個分支中修復。 錯誤修復更改的分支應從所有需要該修補程序的分支的共同祖先分出。

--o--o--o--o    production 
     |\ 
     | \------o--o bugfix-1 
      \ 
      o--o--o  development 

一旦修復後，將它合併到兩個production和development。這是可能的，因爲bugfix-1是從兩個分支的共同祖先分出的。

--o--o--o--o----------o production 
     |\   /
     | \------o--o  bugfix-1 
      \   \ 
      o--o--o-----o development 

而不是隻使用共同的祖先，你甚至可以從引入錯誤的提交中分叉錯誤修復分支。這將確保錯誤修復可以合併到任何可能的分支中，該分支本身包含有缺陷的提交（因爲在完全分佈式系統中，您可能不知道所有使用有缺陷提交的分支）。

從A successful Git branching model分支的「熱修復」分支是這種類型的工作流程的變種。 Git的維護者有一篇關於the purposes of branches的博客文章，這可能也有助於闡明應該如何/爲什麼創建分支，以及如何有效地使用它們的內容可能在多個後代分支中使用它們（例如，爲什麼您可能想避免合併「上游」分支到一個功能分支）。

---

如果你工作周圍的其他方式（叉錯誤修復分支從提交，這只是你的目標的一個分支），你最終將不得不「重放」（即「櫻桃挑」或「rebase」）從錯誤修復分支到其他目標分支的個別更改，而不是進行正常的合併。這種方法可行，但這意味着您必須跟蹤錯誤修復分支的所有變體，以驗證特定目標分支是否包含錯誤修復（或版本）（或退回到手動代碼檢查）。

修復「development之上」的錯誤。

--o--o--o--o    production 
      \ 
      o--o--o   development 
        \ 
        b--b bugfix-1 

它合併到development（例如顯示所謂的「非快進」在Git的合併），以及重訂/櫻桃挑bug修復提交（b）上production（b'），因爲合併development到production將是一個壞主意，但並不是所有的內容是爲生產做好準備：

--o--o--o--o--b'--b'  production 
      \ 
      o--o--o------o development 
        \ /
        b--b bugfix-1 

還有就是b提交，並在production分支b'提交之間沒有記錄的關係。這種缺乏關係意味着如果您想以自動方式回答「某些分支，W，是否有錯誤修復？」這個問題，則您必須詢問b和b'提交。