從CVS概念/限制中釋放工作流程

我正在將我們的VCS從CVS遷移到Git，我仍在努力嘗試最佳地調整我們的工作流以適應Git，但我仍然有一些疑問。我們沒有生產環境，我們定期發佈版本，並由我們的客戶在生產環境中部署。所以我們的工作流程與那裏的團隊有點不同。我們經常有幾個版本並行開發，有些版本需要與更高版本集成。這裏有一個簡單的例子：從CVS概念/限制中釋放工作流程

現在，想象一下，V1.0已完成並正在發佈給我們的客戶。此時，我們需要將此分支與V2.0和V3.0合併，並且這些分支正在開發中（爲了保持簡單，我沒有考慮其中某些分支可能不適用某些分支的情況，例如修復了某些功能被中斷了以後的分支），這將創建一個類似於此的一個歷史：

隨着V1.0「關閉」，我們開始對V1.1工作。我們使用CVS的方式，我們將有一個分支代表每個版本的HEAD，例如。 V01_HEAD，從那裏創建了一個新的分支，例如， V01_00，做一些工作，提交，切換到V01_HEAD，從V01_00合併，提交，標記，切換到V02_HEAD，合併V01_HEAD，提交，切換到V03_HEAD，合併V02_HEAD，提交等。之後，我們將從V01_HEAD創建V01_01，並重復Cicle。正如你所想象的那樣，保持最新的東西是棘手的，費力的，痛苦的，並且合併衝突非常頻繁，因爲我們需要跟蹤所有正在開發的分支，並且需要確保我們不忘記合併到其中的一個分支上部分支。在不同分支中更改相同的代碼塊也是很常見的，因此存在衝突。當我們有時有4個或更多平行發展時，挑戰會增加。碩士的分支唯一的目的是作爲新版本的基礎。我們也有額外的挑戰。想象一下，有人正在從事V1.12的工作，並對幾個班級進行財務調整。其他合作者正在V2.5和V3.0上的其他合作者。在合併V1.12之前，其他版本將基於可能被棄用的代碼進行工作。

這是否相同的理念做出的Git任何意義還是更具有較小的和更長的運行分支（例如V1，V2，V3等），只是標記它合併到更高的分支之前提交？

由於這是一個全新的開始，與CVS相比，Git提供了更多的選擇，我只想確保我們選擇的工作流程不會引入不必要的熵。我需要來自Git /版本控制專家的可靠建議。

我希望我已經清楚地解釋了這個問題。

來源

2016-12-12 EPMS Devteam

我建議在[SoftwareEngineering.SE]上檢查[我自己關於分支和標籤的問題]（http://softwareengineering.stackexchange.com/questions/165725/git-branching-and-tagging-best-practices）（以前是程序員）當我第一次學習Git時。 –

感謝您的鏈接，我會看看。 –

這不是一個答案，而是如果你使用CVS，很可能這是一箇舊的項目，人們被設置爲他們的CVS方式。給你的團隊更多的時間比你期望的只是學習理解git。（如果你的團隊足夠小以至於可以做到這一點，可以強迫他們進行某種訓練，或者定期舉行補習課程，只有這樣他們才能理解你可能要求他們在git中做的所有「瘋狂的事情」）首先使用git，也許只是做相同的CVS工作流程，直到他們準備好進行第二次重大更改爲止。 – Mort

是的，這個哲學在Git上也有意義。但是你也可以設計一個不同的結構，因爲你需要同時開發v1.x，v2.x和v3.x，你可以創建3個發佈分支v1，v2和v3。 v1.0，v1.1，v1.2等版本可以通過標記和提交信息進行標記，因此您可以輕鬆找到它們。有a successful git branch module供您參考（因爲您的要求與此不同，如果您想要應用此模塊，您必須進行一些更改）。

C1---C2------C3------------------C7 
     \  \     \ 
     \  C6--C8--C10(V2) C9--C11(V3) 
     \   /______________/ 
      C4-----------C5---C12---C13 (v1) 
         |  |  | 
        V1.0 v1.1 v1.2

而且它也不需要標記合併提交之前，您可以添加標籤的歷史承諾通過git tag –a v1.0 <commit id> -m 'message'。

來源

2016-12-13 02:31:01

感謝您的詳細解答，鏈接似乎非常有幫助。 –

我的榮幸。如果答案對您有幫助，請將其標記。它會幫助其他人有類似的問題:) –

我會，我只是在接受答案之前等待進一步的貢獻（如果有的話）。 –

從CVS概念/限制中釋放工作流程

回答

相關問題