Git分支模型：幾個問題

Question

我們幾乎已經適應了一個分支模型，在該模型中，我們有一個代表生產代碼的master分支和一個代表未來版本的release-xx分支。

但是，在某些情況下我們不確定如何有效解決：

實時錯誤修復與當前版本無關

1. release-2.0分支了一項新feature ，並完全重寫了模塊A。

2. 新feature已完成並合並到release-2.0 。

3. 找到當前在線模塊A中的錯誤並將其修復在master 。

至此，我們發現有兩種可能的情況：

1. 我們以release-2.0以master為基礎，以提供錯誤修復和修復沖突（丟棄現在不相關的錯誤修復代碼）。 最終，當發布就緒時，我們然后將release-2.0合並到master 。

2. 我們僅將與該發行release-2.0相關的錯誤修復挑選到release-2.0 ，當發行版准備就緒時，我們將使用release-2.0歷史記錄覆蓋整個master歷史記錄。

解決方案1迫使我們解決與不需要的提交發生合並沖突的問題，但是解決方案2迫使我們擦除整個master分支，並在每個發行版中將其替換為release-2.0分支的歷史記錄。 這帶來了丟失我們在release-2.0上遺忘的錯誤修復的機會，並且還可能破壞發行版之前master分支的正在進行的錯誤修復。

畢竟，某項功能無法進入發布

1. 我們創建了一個新feature ，基於release-2.0並使用--no-ff將其合並到release-2.0 。
2. 發現了一些錯誤，因此我們在feature對其進行了修復，然后重新執行上述合並過程。
3. 客戶再次檢查該功能，並決定要更改許多功能-如果沒有這些功能，該功能將毫無價值，但是我們無法對release-2.0進行這些更改，而必須等到release-3.0 。

處理這種情況的正確方法是什么？ 我們是否應該使用諸如“還原功能X-推回3.0”之類的消息來還原在release-2.0中完成的與該功能相關的所有提交，然后再將feature合並到release-3.0 ？

Answer 1

首先 ，如果您同時在release-2.0和master分支中更改了模塊A，並且要將對master的模塊A的更改應用到release-2.0分支。

除了您列出的solution1和solution2之外，還有另一種方法，您只能將模塊A的更改從master更改為release-2.0 。 那就是直接從master到release-2.0簽出相關文件，然后提交changes 。 詳細步驟如下：

git checkout release-2.0
git checkout master /path/to/moduleA  
# Such as git checkout master moduleA/*
# Now module A is what you changed in master
git commit

其次 ，在大多數情況下，如果您使用版本格式為xy （major.minor），則x （major）代表客戶端所需的主要/重要更改，而y （minor）則表示我們修復了錯誤或客戶端在需要時幾乎不需要更改他們會審查您所做的工作。

因此，如果您的客戶在查看2.0版時要求進行大的更改，則可以將項目開發為3.0版。 完成工作后，您的客戶將查看3.0版本。 如果他們報告了3.0版本的錯誤或微小更改，則可以將版本更改為3.1（將release-3.0分支重命名為release-3.1或者在完成更改后添加標簽3.1）。

此外 ，還有另一個不同的分支模塊，您可以參考：在develop分支上工作->完成工作時->將develop合並到release分支中->在批准/審查release分支之后->將release合並到master分支中->記錄標簽中的發行版本。

Answer 2

我建議使用標簽而不是分支來代表生產中的產品。 這樣，您可以簡單地簽出一個新的修補程序分支並修復您的錯誤，然后直接部署此提交並將其標記為當前的生產代碼，如果您知道一切都會更改下一個版本，則無需將其合並回來。

* 54c82e0 - (HEAD -> master) Commit6
* bb6db8e - Commit5 
* 5156c9f - Commit4 
| * 630a150 - (tag: v1.1) Hotfix commit 
|/
* db5c984 - (tag: v1.0) Commit3 
* 00c6c5c - Commit2 
* 715412a - Commit1 

您將使用計划的分支模型，但是master將成為您的“主干”，所有工作都將被合並到其中，而當前的生產代碼將始終帶有一個標簽，您可以從中簽出是否需要修補程序。

我會盲目選擇“經過驗證的”分支模型（如GitFlow）時要小心，因此我認為您處在正確的軌道上，試圖找出適合您需求的模型。 有關更多閱讀，請參閱：

• Git合作-從幻想到運作
• GitFlow被認為有害
• trunkbaseddevelopment.com