如何維護兩個或更多不合並的分歧分支？

我保持混帳一個Redis Sentinel library for Laravel有兩個積極的發展分支：如何維護兩個或更多不合並的分歧分支？

1.x ... o ———— o —————— o — o — o — o — o ... 
      ↘    ↑ ↑  ↖ 
2.x (breaking change) — o — o — o — o — o ...

如上圖所示，我分叉1.x的以適應從這個庫集成框架的新版本重大更改，但我發現自己提交或手動複製分支之間的代碼，以更新兩個分支中的通用功能。

這似乎是因爲他們各自包含的代碼是不與其他兼容我永遠不能合併這些分支機構。我可以採取哪些更好的工作流程來減少合併分支間常見更改所需的工作量？

來源

2017-10-01 Cy Rossignol

的老問題。分支或不分支。

真的是沒有靈丹妙藥這裏。他們必須保持分歧的原因是什麼？如果他們都不想再一起迴歸，由於類似新架構的實現，那麼是否有理由不能將1.x遷移到2.x或在宣佈的一段時間後完全棄用1.x等。？

這些通常必須做出艱難的抉擇 - 棄用並停止支持，因爲與不斷合併相關的維護開銷舊的或不同的變化，或者只是忍受它。只要意識到，如果你和它一起生活，你就會花費時間在那些本來可能花費在新功能上的開銷。

分支保持發散，沒有計劃，以消除差異的時間越長，技術債務，你很可能有讓你忙定期，並可能越來越大。

我意識到這不是一個解決方案，但我不知道其他選擇 - 如果你打算在沒有計劃的情況下允許差異將來重新組合，那麼將會有差異並且持續的維護將會是無論你想保持不變，都需要它。我不知道任何其他答案，但沒有深入瞭解您的特定項目的細節。

來源

2017-10-01 05:04:01 LightCC

感謝您的中肯的意見。這是我擔心的。 * 1.x *分支在今年年底不推薦使用，但我希望能夠爲未來學習一些技巧或工作流程。分支無法合併，因爲它們都依賴於版本之間更改的外部代碼（以及將每個分支約束到這些版本的程序包管理器元數據）。我會把這個開放一段時間，但我希望這是對這些情況可能的最佳答案。 –

在外部依賴性差異的情況下，您可以實現一個接口還是使用其他方法來允許代碼在編譯時或在運行時選擇外部庫的哪個版本？這實際上是將它們合併到一起的一種手段 - 並且將以應該使更新更容易的方式分離每個版本的代碼。但是，這可能並不值得，尤其是如果您在2017年底棄用1.x。 – LightCC

我可以，而且我確實使用此方法處理項目需要支持的框架版本之間的輕微不兼容問題，但是，在這種情況下，這種差異足夠大，我沒有看到這樣做的價值。太多的運行時條件（畢竟是PHP）會帶來複雜性和開銷，我認爲我不能將這些代碼強制到一個分支中。再次感謝您的時間 - 在閱讀您的建議後，我對分叉的決定感到更好。我想我正在尋找那個神奇的子彈！你已經給了我一些關於未來項目的想法。 –

如何維護兩個或更多不合並的分歧分支？

回答

相關問題