源代碼管理和錯誤修復的最佳實踐

Question

如果我們需要發佈一個不包含當前已提交的開發或者與當前版本相比發生的任何更改的錯誤補丁，應該採取什麼措施使此過程更安全，高架？

我們目前在一個主要在Visual Studio 2008中開發的小型（3個開發人員）團隊中使用Subversion進行源代碼管理。我們預計該團隊可能會在明年與8個開發人員進行分組，併爲以前的任何版本提供支持變得更加複雜。雖然大多數客戶都在使用最新的版本，但有些版本進一步落後。

Answer 1

源代碼管理可以很容易地處理這個問題，並且是爲此設計的。

當您達到發佈的穩定期時，應該完成一個分支。在完成此操作之前，不要在下一個版本中開始任何工作，這一點很重要。

該版本的任何錯誤修復都應該在該分支中完成。這可以防止即將發佈的新代碼污染錯誤修復。一旦錯誤修復完成後，您可以將該更改合併到中繼，以及任何其他版本（如有必要）。

不要忘記在註釋中加入錯誤號，因爲這樣可以更輕鬆地跟蹤提交。

Answer 2

怎麼樣：每個主要版本的分支，根據需要將錯誤修復應用於分支，並且還應用（或合併）回主幹。

Answer 3

我在哪裏工作，我們有幾個項目同時工作。爲了避免這個問題，我們有幾個源代碼版本。例如，第一個版本是Variant 1.0。我們在這個版本中創建了一個分支，比如Variant 2.0，用於所有未來的開發。如果我們需要修復漏洞，我們會在主要的Variant上進行修改，它目前是1.0，並且可以釋放它。當Variant 2.0準備好投入生產時，我們將它與主分支上的任何東西（在本例中爲1.1）合併，併成爲新的主幹。有一次，我們有4個分支同時運行。

合併代碼可能非常耗時，並且在合併期間必須小心不要引入新的錯誤，但是如果您有可用的體面代碼比較工具，那麼它不應該太糟糕。我們在10000個文件源目錄中使用Beyond Compare進行了一次合併，並且花了一個早上。