用于维护多个版本的git分支

Question

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

然而，文章中有一个隐藏的假设，它来自master分支的存在：后者发布，版本越大。例如2.0.1始终在1.5.10之后发布。因此，当您遍历master中的每个提交时，版本将始终增加。

这不适用于我们的项目案例。我们必须为不同的客户维护多个版本。对于一个客户，我们必须为版本1.5支持（并提供修复），对于另一个客户，版本为2.0。显然，在我们的案例中，版本1.5.10可以比版本2.0.1更晚（在时间方面）。 <{1}}提交后1.5.10提交master毫无意义。

文章的模型根本不适合我们，或者我们可以稍微修改它以使其有效吗？

Answer 1

众所周知，对相应的主要版本有不同的分支。

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

您应该单独维护发布分支，并决定要向每个发布分支提交哪些提交。

了解您熟悉的着名项目以采用您的发布模型并了解其存储库策略总是很好的。以下是使用git scm https://github.com/django/django/branches

维护几个主要版本的好例子

Answer 2

Master应该只反映当前版本，这就是我实现它的方式。任何其他版本都在其分支上。

E.g

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

分支V1上的提交不再是主历史记录的一部分，V2历史记录已与主服务器合并。因此，您的日志中不应存在任何历史记录。