2014-09-30 28 views
0

我最近繼承了一個沒有版本控制的ASP.Net Web窗體項目,我試圖將它移入TFS。在某個時候,項目被拆分爲一個客戶端的定製版本,其中登錄使用ADFS而不是我們的數據庫驅動的表單。拆分後,一些功能被添加到主版本中以管理用戶;這些在自定義版本中不需要。對一個版本的任何更改都會被手動應用到另一個版本(如果它們影響到非定製部件的話)(儘管可以預見,這有時會被遺忘)。TFS分支的自定義版本,排除這些自定義從合併?

每個版本有開發和生產服務器上的文件夾,這樣的文件夾結構是這樣的:

/Production/General 
/Production/Custom 
/Dev/General 
/Dev/Custom 

假定這將是困難的兩個版本,功能切換完全合併,什麼是最好的方法來管理這個?

我在想我可以使用差異來拉出生產版本的共同點,並使我的主要分支。然後,我可以從主讓兩個生產版本分支,有其當前的狀態作爲第一個辦理登機手續,然後做類似的事情在開發文件夾,如:

- MAIN 
    | |- General 
    | |- GeneralDev 
    | 
    |- Custom 
    |- CustomDev 

但是,我不知道如何管理合並。有沒有辦法阻止某些文件僅在特定分支之間合併?如果我在CustomDev中進行了更改,我想將它正常地合併到General中,那麼我希望能夠將此更改轉換爲General和GeneralDev,而不必將Custom的所有其他自定義設置爲...

Is there a這樣做的方式(無需每次合併時都排除文件),還是隻需將這些視爲兩個單獨的項目並手動同步更改?

回答

0

使用分支機構應該簡化合並操作,只需手動完成,因爲分支機構可幫助您瞭解更改的歷史記錄。您可能需要定義一個合併的謹慎程序,以確保合併總是正確完成 - 這可能涉及限制允許合併的人員,因爲經常有太多廚師可能會損壞湯汁。

但是,考慮到在這種情況下不斷增加的合併成本和風險 - 這是一項巨大的技術債務,因爲任何需要合併的變更都需要4倍的成本才能實現。只是測試兩個分支不受小變化的影響是很困難的,因爲您必須檢查併合並,然後才能確定它是否正常 - 最好能夠在您的PC上構建兩種變體並在您檢查任何內容之前對其進行測試in。

至少你應該儘量減少所需的合併,所以看看你可以在什麼地方重構代碼庫(可能會逐漸逐漸減少)以減少合併的需要。看看你得到最多合併流失的代碼。也許你會發現,在你的登錄類中有幾個需要合併的方法,其餘的可以共享 - 所以使用分類或單獨的cpp文件或將代碼分解成助手或派生類 - 任何可以實現將這些方法分解爲單獨的文件。然後,只需要合併共享的一段代碼,而不必連續不斷地合併每個更改。隨着時間的推移,您可能能夠正確隔離和模塊化非共享代碼。

但是,我建議不要在任何合併必須雙向的情況下進行分支。

另一種方法是分支合併和逆合併。對兩個代碼庫進行區分,並在任何有區別的地方將代碼的兩個變體放在一個條件編譯塊(#if ...#else ... #endif)中,以便可以從一組源代碼文件。這很醜陋,但允許您在沒有任何分支或合併的情況下處理代碼 - 您的開發人員仍需記住編譯這兩種代碼的變體,以確保他們的更改能夠在兩個版本中工作,但這比合並並重建這兩個變種。再次,隨着時間的推移,尋求模塊化差異,以便可以最小化和/或聚合以最小化影響。這種方法也可能允許將行爲的某些部分更改爲運行時而不是編譯時選擇,因此一些行爲可以以不同且更有用的方式重新使用。使用體面的差異工具(例如Araxis Merge),即使使用大型代碼庫,這也不算太糟糕。幾天的重構痛苦可以爲您節省多年的麻煩。

我知道我在暗示你想要避免的事情,但越早解決技術債務就越痛苦。在短期內平滑症狀與分枝會更容易,但永遠不會解決潛在的問題......而技術債務的事情是,越久離開它越糟糕。