分支策略 [英] Branching Strategies

问题描述

我工作的公司开始对他们当前的分支模式产生疑问，我想知道社区接触到哪些不同的分支策略？

有针对不同情况的好方法吗？贵公司使用什么？它们的优缺点是什么？

解决方案

下面是我过去使用的方法，该方法取得了很好的成功：

/ trunk-前沿。该代码的下一个主要版本。

/branches/1.0、1.1等。代码的稳定维护分支。用于修复错误，稳定新版本。如果是维护分支，则应在任何给定时间进行编译（如果适用）并准备进行质量检查/装运。如果是稳定分支，则应编译并完成功能。不应添加任何新功能，不进行重构以及不进行代码清理。您可以添加一个前缀来表示稳定分支与维​​护分支。

/ branches / cool_feature。用于可能会也可能不会进入主干（或维护分支）的高度实验性或破坏性工作。不保证有关代码的编译，正常运行或其他行为。

/tags/1.0.1、1.0.2、1.1.3a等，应该在合并到主线分支之前持续最短的时间。用于标记a包装和发货。永远都不会改变。制作任意数量的标签，但它们是不可变的。

The company I work for is starting to have issues with their current branching model and I was wondering what different kinds of branching strategies the community has been exposed to?

Are there any good ones for different situations? What does your company use? What are the advantages and disadvantages of them??

解决方案

Here is the method I've used in the past with good success:

/trunk - bleeding edge. Next major release of the code. May or may not work at any given time.

/branches/1.0, 1.1, etc. Stable maintenance branches of the code. Used to fix bugs, stabilize new releases. If a maintenance branch, it should compile (if applicable) and be ready for QA/shipping at any given time. If a stabilization branch, it should compile and be feature complete. No new features should be added, no refactoring, and no code cleanups. You can add a pre- prefix to indicate stabilization branches vs maintenance branches.

/branches/cool_feature. Used for highly experimental or destructive work that may or may not make it into trunk (or a maintenance branch). No guarantees about code compiling, working, or otherwise behaving sanely. Should last the minimum time as possible before merging into the mainline branch.

/tags/1.0.1, 1.0.2, 1.1.3a, etc. Used for tagging a packaged & shipped release. Never EVER changes. Make as many tags as you want, but they're immutable.

这篇关于分支策略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！