多個網站，單個代碼庫：git fork？

我工作的一個Web應用程序是一箇舊的遺留系統，最近已經遷移到git。該系統相當龐大。兩個不同的網站運行這個相同的軟件;然而，代碼的很多部分使用簡單的控制語句（如果site =='this'{do custom business logic;}）來執行特定於站點的事情。這個策略已經使用了十多年了，而且越來越難看了。多個網站，單個代碼庫：git fork？

由於代碼庫的很大一部分已經在兩個站點之間分歧，我們正在考慮分叉庫。棘手的是，大部分代碼在兩個系統之間合法共享。因此，如果在共享代碼中修復了一個錯誤，那麼修復進入分支似乎會非常棘手。例如，我們可以使用補丁。或者，我們可以在叉點創建分支，挑選更改，然後使用拉取請求。但是這兩種方法對我來說都過於複雜，我想盡量減少複雜性。

現在的問題。 分叉似乎是一個很好的方法嗎？我們是否應該使用分支機構，然後選擇修復/增強共享代碼？

另外，我會再次強調這是一個很大的遺留系統。我們一直致力於改進系統，將共享JavaScript模塊放入自己的存儲庫並在NPM中發佈這些模塊。（我們正在遵循Michael Feather的書中提出的指導原則，與遺產代碼有效地合作）。這就是說，改進大型遺留系統是一個緩慢的過程。我們希望儘量減少重構，並不斷進行緩慢的改進。

來源

2017-09-22 avejidah

你提出的只是另一個版本的「越來越難看」的方法，你已經有了。它並不能真正解決問題，它只會讓別的東西變得醜陋。相反，我會建議一些重構。從代碼庫中提取共享代碼，並有兩個引用共享代碼的獨立應用程序，或者從代碼庫中提取不同的代碼，並有一個應用程序根據某些應用程序配置動態加載特定於站點的庫。 – David

謝謝@戴維。我真的很同意這一點，這是我們迄今爲止選擇的方式（例如通過將共享代碼移動到npm模塊）。但重構需要的時間很長，因爲我們有破解經過時間檢驗的代碼的風險。我真的很想使用一個工具（git here）來幫助緩慢，安全和精心策劃的重構工作。我們希望保持一個系統完好無損，只需更換其他系統，但當然會傳播任何修復程序。但是，也許，如你所說，這不是一條好路徑。無論如何，感謝您的評論。 – avejidah

這確實是一個標準的商業問題。技術債務多年來一直在積累，團隊一起決定「以後再處理」。歡迎來到以後:)在這一點上的選擇是承擔成本並糾正現在的問題，或者增加更多的技術債務，並在以後以更高的成本「處理它」。這兩種方法都是有效的方法，取決於風險和成本的權衡。 – David

你知道有大量的重複代碼將成爲一個問題。很有可能一旦這些網站存在於不同的回購站中，它們會以不同的方式交換補丁，難以正確完成，這不是最終的結果 - 這意味着您最終會通過兩項獨立的開發工作來修復每個缺陷。我無法想象與目前「基於站點ID的分支」方法相關的問題會比這更糟糕。我知道一個大系統的勢頭，但如果你選擇一個系統的方式來分離普通代碼和發散代碼 - 而不必擔心（但是）分裂各個公共模塊，而只是朝着3 -repo解決方案 - 你可以比你想象的更快。

來源

2017-09-22 17:27:34

Mark：謝謝你的迴應，但你能澄清幾點嗎？ 1）當你說「基於站點ID的分支」你的意思是代碼分支，對吧？（而不是VCS。）2）當您說3回購解決方案時，您是否建議使用通用代碼的回購協議，然後兩個分支（每個站點一個）？我們正在尋找一種隨時間會持續下去的系統性方法，我們不希望加劇目前的問題或在這裏採取捷徑。由於我們試圖分解代碼的一部分，因此我們需要一種可以理解，具有成本效益的方法，並隨着時間的推移緩慢地改進系統。 – avejidah

1）是的，我指的是代碼中的邏輯分支。我的意思是說，跟你現在的情況一樣糟糕，簡單分支中涉及的通用代碼問題更糟。 –

2）3-repo解決方案可以將常用代碼保存在一個回購站中，站點1代碼存儲在一個回購站中，而站點2代碼存儲在一個回購站中。我不會使用任何叉子去解決這個問題。 –

多個網站，單個代碼庫：git fork？

回答

相關問題