如何在Git中實現語義版本控制？

Question

我已經能夠說服我的小組使用語義版本控制並轉移到git（來自CVS，所有開發都發生在主干上）。

這就是我們一直在使用的東西（版本分支表示某種新功能的引入）：

master
*
|
*   * version 2.0 branch
|  /
* *
|/
*   * version 1.0 branch
|  /
* *
|/
*
|
...

問題是，當需要在版本1.0分支上進行錯誤修復時，該修補程序需要回顯到版本2.0和主數據庫。 我們一直在挑選，但我覺得這比我想要的更容易出錯（我覺得隨着時間的推移它會變得無法管理）。

我們正在做的事情有一些限制 - 它是遺留代碼，並且沒有進行大量測試（開始引入單元測試，非常少的集成測試），因此保持這些版本分支的穩定性（不介紹很多回歸錯誤）很重要。

你們有沒有比采摘櫻桃更好的方法來解決這個問題？ 有更好的工作流程可供使用嗎？ 非常感謝您提供的任何幫助。

Answer 1

櫻桃采摘可以：

• 引入重復提交
• 錯過功能依賴

我更喜歡合並 （類似於desert69 提到的成功的Git分支 ）：

• 創建一個專用於buxfix_xxx的分支（在版本1之上）
• 將version1合並到該buxfix_xxx分支（快進）
• 將buxfix_xxx合並到version 2和master分支

當然，訣竅是在這些分支（版本2和主版）中記錄合並而不實際合並所有文件：請參閱“ 如何使用git-merge合並選擇性文件？ ”。

如果你只有幾個文件要合並，我就是這樣做的：

# make git believe we are merging everything
git checkout version2
git merge --no-commit bugfix_xxx

# but reset everything to version2
# (while the merge is still in progress!)
git checkout version2 -- .

# merge only the few files we need:
git checkout --patch bugfix_xxx -- path/to/file1
git checkout --patch bugfix_xxx -- path/to/file2
git checkout --patch bugfix_xxx -- path/to/file3

# add and commit, concluding the merge

關於那些合並的好處是，下一個（從version1到version2和master ）將自然限於下一個錯誤修復，因為git將相信其他一切 已經合並 ！

因此，您投入第一個錯誤修正后端的時間將為下一個支付費用。