git分支维护几个版本

Question

我正在考虑如何在我们的项目中管理git repo中的分支。 我读过famous article，非常喜欢这个主意，看起来这个模型应该对我们有用。

然而，在文章中有一个隐藏的假设，它来自master分支的存在：后者的发布，其版本越大。例如2.0.1总是在1.5.10之后被释放。所以当你遍历每个提交的主版本将会增加。

这不适用于我们的项目案例。我们必须为不同的客户维护几个版本。对于一个客户，我们必须为版本1.5提供支持（并提供修复），对于另一个客户，版本为2.0。在我们的例子中显然版本1.5.10可以比版本2.0.1来后者（在时间上）。在提交2.0.1后承诺1.5.10变成master是没有意义的。

是文章的模型根本不适合我们，或者我们可以修改它一点点以使其工作？

Answer 1

主人应该只反映当前版本，这是我已经实现它。任何其他版本都在其分支上。

E.g

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

提交分支V1是主的历史不再一部分，V2历史已经合并了主人。所以没有历史记录应该在你的日志中冲突

Answer 2

已知的做法是为相应的主要版本设置不同的分支。

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

比你应该分开维护你的发布分支，并决定你想提交给每个发布分支的提交。

查看您知道的采用您的发布模型并了解其存储库策略的着名项目总是很好的。这里是使用git scm保持几个主要版本的好例子。https://github.com/django/django/branches