分支策略
我工作的公司开始有他们目前的分支模式的问题，我想知道社区已经接触到什么不同的分支策略？
对于不同的情况有什么好的吗？ 你的公司使用什么？ 他们的优点和缺点是什么？
以下是我过去成功使用的方法：
/树干 – stream血的边缘。 下一个主要版本的代码。 可能在任何时候或可能不工作。
/branches/1.0,1.1等代码的稳定维护分支。 用于修复错误，稳定新版本。 如果维护分支，它应该编译（如适用），并准备在任何给定的时间进行质量保证/运输。 如果一个稳定分支，它应该编译和function完整。 不应该添加任何新function，不要重构，也不要执行代码清理。 您可以添加前缀来指示稳定分支与维护分支。
/支链/ cool_feature。 用于高度实验或破坏性的工作，可能会或可能不会成为树干（或维修分支）。 没有关于代码编译，工作或其他行为的保证。 在合并到主线分支之前应尽可能保持最短的时间。
/tags/1.0.1,1.0.2,1.1.3a等。用于标记打包和发布的版本。 永远不会改变。 尽可能多的标签，但它们是不变的。
我强烈build议您阅读Eric Sink对此事的看法：
第7章：分支
我和Eric一样，更喜欢他所说的“文件夹”式的分支。
对于分支模式的母亲来说，请参阅Brad Appleton的Streamed Lines：并行软件开发的分支模式 。 这是沉重的责任，但我还没有看到任何东西超越分支知识的广度和深度。
我们的仓库看起来像：
/trunk /branches /sandbox /vendor /ccnet /树干是你的标准，发展的前沿。 我们使用CI，因此必须始终构build并通过testing。
/分支这是我们把“认可”的巨大变化的地方，也就是我们知道的东西会变成树干，但可能需要一些工作，会破坏CI。 还有我们在维护版本上的工作，这些维护版本有自己的CI项目。
/沙箱每个开发人员都有自己的沙箱，还有一个共享的沙箱。 这适用于“让我们添加一个LINQ提供程序到我们的产品”types的任务，当你没有做你真正的工作时。 它最终可能会进入主干，它可能不会，但它是在那里，并在版本控制下。 这里没有CI。
/供应商标准供应商分支为我们编译的项目，但它不是我们维护的代码。
/ ccnet这是我们的CI标签，只有CI服务器可以在这里写入。 事后看来会告诉我们把这个更名为CI，BUILDS等更通用的东西
- 活跃发展的一个分支（/主或主，根据行话）
- 每个维护版本的一个分支 – >它只会收到非常小的修复，而所有主要的发展都是以/ main为主
- 每个新任务的一个分支：创build一个新的分支来处理Bugzilla / Jira / Rally上的每个新条目。 经常提交，使用英寸卵石检查自我logging更改，并且只有在完成并经过良好testing后才将其合并回“父”分支。
看看这个http://codicesoftware.blogspot.com/2010/03/branching-strategies.html更好的解释;
第一件事： KISS （保持简单愚蠢！）
/枝 /RB-1.0（* 1） /RB-1.1（* 1） /RB-2.0（* 1） /标签 /REL-1.0（或者你的版本看起来像例如1.0.0.123 * 2） /REL-1.1 /REL-2.0 /树干 目前的开发与很酷的新function;-)
* 1）保持版本可维护 – 例如，Service Pack，修补程序，错误修复，如果必要和/或需要可以合并到主干）* 2）major.minor.build.revision
大拇指的规则：
- 标签文件夹不需要检出
- 在发布分支中只有很less的代码（使合并更简单） – 没有代码清理等。
- 永远不要在标签文件夹中编码
- 切勿将具体的版本信息放入源文件。 使用占位符或0.0.0.0，构build机制将由您正在构build的版本号replace
- 永远不要把第三方库放到源代码控制中（也没有人会把STL，MFC等库添加到SVN中;-)）
- 只提交编译的代码
- 优先使用环境variables而不是硬编码path（绝对path和相对path）
–hfrmobile
当发布版本准备好进行最终质量检查时，我们会进行分支 如果在质量保证过程中发现任何问题，则错误在分支中被固定，validation并合并到中继。 一旦分支通过QA，我们将其标记为发布。 该版本的任何修补程序也完成到分支，validation，合并到主干，然后标记为单独的版本。
文件夹结构如下所示（1个QA行，2个修补程序版本和中继）：
/枝
/REL-1.0
/标签
/REL-1.0
/REL-1.0.1
/REL-1.0.2
/树干
我们使用野生，野生，西方风格的分支。 我们有一些按照惯例定义的知名分支机构，但在我们的案例中，标签实际上对于我们来说更符合我们的企业stream程政策要求。
我在下面看到你使用Subversion，所以我想你可能应该看看在Subversion书中分支部分。 具体来说，查看分支维护和常见分支模式中的“存储库布局”部分。
我在这里没有看到的是“变革的分支”哲学。
如果主干是“当前版本”，那么不要让你的主干为“狂野的西部”？ 如果一次只发布一个版本的应用程序，比如一个网站，就可以很好地工作。 当一个新function或错误修复是必要的，一个分支是保持这一变化。 通常这可以将修复程序迁移到单独发布，并防止牛仔编码人员意外添加一个function，以释放您不想要的function。 （通常这是一个后门 – “仅用于开发/testing”）
本柯林斯的指针在确定哪种风格适合你的情况下非常有用。
Henrik Kniberg 对多个敏捷团队的版本控制也有一些好的方面要考虑。
我们目前有一个分支机构正在进行维护，一个分支机构的“新举措”只是意味着“将来会出现的东西，我们不知道什么时候。” 我们偶尔还会有两个维护分支：一个为目前正在生产的产品和一个仍在质量保证中的产品提供修复。
我们看到的主要优势是能够更快速地响应用户请求和紧急情况。 我们可以对正在生产的分支进行修复并释放它，而不会释放任何可能已经签入的额外内容。
主要缺点是我们最终在分支之间进行了大量的合并，这就增加了错过或错误合并的可能性。 到目前为止，这并不是一个问题，但这绝对是要记住的。
在我们制定这个政策之前，我们通常在干线上做了一切发展，只有在我们发布代码时才分支。 然后，我们根据需要对该分支进行了修复。 这很简单，但不够灵活。
杰夫·阿特伍德在一篇很好的博客文章中写道 ： 那个post里面有一些重要的链接。
Gnat已经写出了这个优秀的分解在你可以find关于分支策略的各种build议。
没有一个分支策略，它适用于：
- 你的团队规模
- 您的产品和生命周期
- 您正在使用的技术（网页，embedded式，Windows应用程序）
- 您的源代码控制，例如Git，TFS，Hg
杰夫·阿特伍德的post打破了很多的可能性。 另一个补充是促销的概念（从瑞安杜菲尔德的链接）。 在这个设置中你有一个开发分支，testingbracnh和发布分支。 直到它到达发行版分支并进行部署后，才会将代码升级。
我们在工作中遵循的理念是保持躯干处于可以随时推动的状态，而不会对场地造成严重伤害。 这并不是说干线总是处于完美状态。 当然会有bug。 但重要的是永远不要把它打破。
如果你有一个function要添加，分支。 devise更改，分支。 我曾经想过很多次，“哦，我可以在后备箱里做这个，不会花费那么长时间”，然后5个小时之后，当我无法弄清楚那个破坏我的东西真的希望我有分支。
当保持行李箱干净时，您可以快速应用并推出错误修复程序。 你不必担心你方便分支的破解代码。
这将取决于您正在使用的版本控制系统。 每个VCS有不同的分支方法。
你使用哪个VSC？
对于Subversion，我同意Ryan Duffield的评论。 他提到的章节提供了一个很好的分析，使用哪个系统。
我问的原因是，Perforce提供了一个完全不同的方式来从SVN或CVS创build分支。 另外，所有的DVCS都有自己的分支哲学。 您的分支策略将取决于您使用的工具。
仅供参考， Svnmerge.py是一个协助合并SVN分支的工具。 只要你经常使用它（每10-30次），它就工作得很好，否则工具会变得困惑。
无论select哪种分支模式，都应该尝试使分支机构保持二进制树forms，如下所示：
trunk - tags | next / \ \ bugfix f1 f2 / \ \ f11 f21 f22
- 子节点只应与直接父节点合并。
- 尝试你最好只合并整个分支与父分支。 永远不要合并分支内的子文件夹。
- 你可以在需要的时候挑选提交，只要你从整个分支合并和挑选。
- 上图中的下一个分支仅用于说明，您可能不需要。
