在Git中管理並行版本的最佳方式是什麼？

Question

我有一個非常成熟的軟件工具包，但它通常需要很小的調整（主要是爲了應付來自第三方產品的兼容性問題）。我現在希望生成一個「新」版本（改進的API），它將基於原始版本 - 這將與現有分支不同，隨着時間的推移，但幾年之後，我將需要保留原始的「現場」爲了兼容性而需要它的現有客戶。當然，我也需要確保「調整」也適用於「新」版本，因爲這些問題（也會在大多數！）也適用於「新」版本。

所以 - 我的理想（簡單）的工作流程是：

1. 在「新」版本中工作時 - 更改僅適用於該 版本。
2. 當處理「舊」版本時，所有產生的變化 都會（儘可能自動）自動應用於兩個版本 ，一旦我對它們感到滿意（當我提交，提交或其他）時。

我意識到需要偶爾進行手動干預，合併是衝突的，但根據過去人工更改的經驗，我認爲這很少見。現在，我正在放棄VSS（是的 - 繼續嘲笑我保持這麼久！），我希望Git能夠讓這個簡單，但到目前爲止，沒有出現到任何「簡單」的解決方案，我看到的建議都是圍繞「rebase」構建的，這對我來說似乎是「錯誤的」，因爲rebase似乎做了很多其他的事情，比如重寫歷史記錄，當我需要的只是一個簡單，真實的「前進」基於來自其他分支的變化。

• 我在這裏錯過了什麼嗎？
• 是否有一個更容易，正確定義的方式來做到這一點？
• 用不同的源碼控制系統而不是Git會更好嗎？

非常感謝所有的想法！

Answer 1

您可以將舊分支的更改合併到新版本。

讓我詳細說明rebase： 除非您唯一的開發人員在代碼庫上工作，否則我不會建議您爲此特定問題使用rebase。記住rebase建議與專用分支機構一起使用，只有自您的重寫歷史記錄，因此使作爲祖先的任何提交失敗的提交無效。

如果您將舊版本分支更改重新分配到新版本，那麼每次需要將舊版本的更改從新版本轉換爲新版本時，您將不斷重寫新版本分支的歷史。這意味着任何在新版本中使用基礎完成的工作，比如新版本獨有的功能的功能分支，將會丟失，因爲原始提交不再存在。

Answer 2

看看Git flow - 一種使用工具支持這些功能的分支方法。基本上，對於每一個新的'調整'，你都會在一個新的分支上進行，這個分支是在你維護的分支的共同祖先之前/之前的，然後你將它們合併到它們中的每一個。