version-control - 分支策略

Question

就目前情况而言，这个问题不太适合我们的问答形式。我们希望答案得到事实、引用资料或专业知识的支持，但这个问题可能会引发辩论、争论、民意调查或扩展讨论。如果您觉得这个问题可以改进并可能重新开放， visit the help center以获得指导。

已关闭 11 年前。

我工作的公司当前的分支模型开始出现问题，我想知道社区接触过哪些不同类型的分支策略？

有没有适合不同情况的好方法？你们公司用什么？它们各有什么优缺点？

Answer 1

这是我过去使用过的成功方法:

/trunk - 前沿。代码的下一个主要版本。在任何给定时间可能工作也可能不工作。

/branches/1.0、1.1等代码的稳定维护分支。用于修复错误、稳定新版本。如果是维护分支，则应编译(如果适用)并在任何给定时间准备好进行质量检查/运输。如果是稳定分支，它应该编译并且功能完整。不应添加新功能，不应重构，也不应清理代码。您可以添加前缀来指示稳定分支与维​​护分支。

/branches/cool_feature.用于高度实验性或破坏性的工作，可能会也可能不会进入主干(或维护分支)。不保证代码编译、工作或以其他方式正常运行。在合并到主线分支之前应该持续尽可能短的时间。

/tags/1.0.1、1.0.2、1.1.3a 等。用于标记打包和发布的版本。永远不会改变。根据需要创建任意数量的标签，但它们是不可变的。