2013-11-15 137 views
0

我正在考慮如何在我們的項目中管理git repo中的分支。 我讀過famous article,非常喜歡這個主意,看起來這個模型應該對我們有用。git分支維護幾個版本

然而,在文章中有一個隱藏的假設,它來自master分支的存在:後者的發佈,其版本越大。例如2.0.1總是在1.5.10之後被釋放。所以當你遍歷每個提交的主版本將會增加。

這不適用於我們的項目案例。我們必須爲不同的客戶維護幾個版本。對於一個客戶,我們必須爲版本1.5提供支持(並提供修復),對於另一個客戶,版本爲2.0。在我們的例子中顯然版本1.5.10可以比版本2.0.1來後者(在時間上)。在提交2.0.1後承諾1.5.10變成master是沒有意義的。

是文章的模型根本不適合我們,或者我們可以修改它一點點以使其工作?

回答

0

主人應該只反映當前版本,這是我已經實現它。任何其他版本都在其分支上。

E.g

V1 (master) -> -> -> \/ -> V2 (master) 
    v2 -> -> -> -> /\ -> V1 (no longer master) 

提交分支V1是主的歷史不再一部分,V2歷史已經合併了主人。所以沒有歷史記錄應該在你的日誌中衝突

1

已知的做法是爲相應的主要版本設置不同的分支。

master仍然是主要的整合分支。

比你應該分開維護你的發佈分支,並決定你想提交給每個發佈分支的提交。

查看您知道的採用您的發佈模型並瞭解其存儲庫策略的着名項目總是很好的。這裏是使用git scm保持幾個主要版本的好例子。https://github.com/django/django/branches