使用分佈式版本控制系統進行版本管理

Question

我們正考慮在工作場所從SVN切換到分佈式VCS。

我很熟悉想要使用DVCS進行日常開發的所有原因：本地版本控制，更容易的分支和合並等，但我沒有看到這麼多的引人注目的內容管理軟件版本。以下是我們的發佈流程：

• 瞭解可用於合併的更改。
• 運行查詢以查找與這些更改相關的缺陷/故障單。
• 過濾出與「打開」票證相關的更改。在我們的環境中，票據必須處於關閉狀態才能與發佈分支合併。
• 濾除發佈分支中我們不想要的更改。我們在合併變更時非常保守。如果更改不是絕對必要的，則不會合並。
• 合併可用更改，最好按時間順序合併。如果它們與同一張票相關聯，我們將更改分組在一起。
• 阻止發佈分支發生的不需要的更改（svnmerge block），因此我們不必再次處理它們。

有時候我們可以一次處理3-5個不同的里程碑。一些里程碑具有非常不同的約束條件，並且阻止列表可能會變得很長。

我一直在搞git，mercurial和plastic，並且據我所知，他們都沒有很好地解決這個模型。當你只有一種產品發佈時，它們似乎能夠很好地工作，但我無法想象使用它們來處理來自同一代碼庫的多種非常不同的產品。

例如，櫻桃採摘似乎是mercurial中的事後考慮。 （你必須使用默認禁用的'移植'擴展名）。在選擇分支後，它仍然顯示爲可用的集成。櫻桃採摘打破了mercurial的工作方式。

DVCS似乎更適合功能分支。如果直接從功能分支合併到發行分支和，則無需進行櫻桃選擇。但是誰想要一直做所有的合併？你如何查詢可用於合併的內容？您如何確保功能分支中的所有更改都屬於同一個組織？這聽起來像是一片混亂。

我很傷心，因爲我的編碼器需要DVCS進行日常工作。我真的很想要它。但是我擔心那天我必須把發佈經理的帽子弄清楚，並且要分清什麼需要合併，哪些不合適。我想寫代碼，我不想成爲合併猴子。

Answer 1

你真的想在這種情況下使用git，因爲它在合併和版本管理方面非常優越。 Git允許簽名過程發佈更改;它實際上提供了對多層發佈管理的支持，正因爲這是Linux的管理方式。

只需將每個版本放入分支。不要阻止你不想要的更改，只需接受你所做的更改，只需簽署發佈即將發佈的更改即可。Git還允許你挑選一組更改爲一個補丁發送到上游，所以你不必將所有'糟糕的，沒有完全正常工作的'補丁放到發行版分支中或存儲庫，只有很好的清潔功能或修補程序。