0

我正在考虑如何在我们的项目中管理 git repo 中的分支。我读过著名的文章，真的很喜欢这个想法，看来这个模型应该对我们有用。

但是，文章中有一个隐藏的假设，这来自于master分支的存在：越是发布，版本越大。例如2.0.1总是在1.5.10. 因此，当您遍历 master 中的每个提交时，版本总是会增加。

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

文章的模型根本不适合我们，还是我们可以稍微修改一下使其工作？

4

2 回答 2

1

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

master仍然是主要的集成分支。

比你应该单独维护你的发布分支并决定你想要交付给每个发布分支的提交。

研究您知道采用您的发布模型并了解他们的存储库策略的著名项目总是很好的。这是使用 git scm https://github.com/django/django/branches维护几个主要版本的好例子

于 2013-11-15T09:57:17.563 回答
0

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

例如

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

分支 V1 上的提交不再是 master 历史的一部分，V2 历史已与 master 合并。因此，您的日志中不应有任何历史记录冲突。

于 2013-11-15T09:55:28.303 回答