TFS 2010 - 重新啓動分支機構時退房

Question

雖然我正在重新設計分支機構，但其餘的團隊仍繼續處理代碼。 Rebase持續約1-2小時。我在上下文菜單中通過右鍵單擊要合併的文件夾進行合併，因此在此處沒有特別之處。

團隊成員簽出代碼，改變它，但他們沒有簽入。這種方法有什麼風險？這種情況的最佳做法是什麼？你的團隊如何處理這種情況？

Answer 1

我認爲你的建議是一個相當標準的方法，只是爲了確保我理解這個問題，這裏是一個場景。

有一個Main分支。從此Main分支2開發分支已創建（devA和devB）這些分支將用於更改2個獨立項目的代碼。

devA開發已達到穩定狀態，並已合併到Main分支。現在您想要將Main中的更改合併到devB

在devB中，開發人員一直在對代碼更改進行編碼並檢出多個文件。您不想讓開發人員檢查對devB的更改，並且您不希望在重新綁定發生時啓動代碼凍結。

如果開發人員在定期，因爲分支產生變化devB被檢查，你會看到porbably合併衝突，當您嘗試合併從Main分支devA變化。有人熟悉這兩個「項目」的代碼和要求將需要幫助解決這些合併衝突。衝突解決後，您可能需要檢查代碼是否編譯以及是否有單元測試運行並通過。如果你有編譯錯誤或單元測試失敗，那麼這將需要調查。

一旦您很高興從Main到devB的合併已經成功，那麼在devB中檢出的文件的開發人員可以開始簽入更改。如果他們已經簽出的文件沒有作爲Main合併的一部分進行更改，那麼這些文件將按正常方式簽入。但是，如果他們檢出的文件已經作爲合併的一部分進行更新，TFS將調出合併衝突解決工具，開發人員需要先解決任何衝突，然後才能檢入代碼。

希望上述內容與您目前所遵循的過程完全接近？如果我錯過了任何東西，或完全錯過了這一點，請告訴我。

這並不是很好，但它是一種常用的方法，我們使用它。

這種方法的風險在於，您最終可能花費大量的時間來修復合併衝突，特別是如果您有很多開發人員在很多分支中更改代碼的代碼量很大。

爲了緩解任何問題，最好儘早和儘可能地重新佈局。早期，因爲如果您將所有內容都保存到devA's項目的末尾，那麼這些更改可能會對devB產生重大影響。通常是因爲每次合併的衝突次數最少，因此解決衝突更簡單，也更不容易出錯。

建立「持續集成」版本也將有所幫助，因爲您會盡早看到編譯問題。如果您使用的是TFS 2010，那麼門控檢查也可能有所幫助。

我不是100％肯定，這個回答你的問題，所以讓我知道如果我錯過了什麼