Question

我工作的公司开始遇到他们目前的分支模式的问题，我想知道社区有哪些不同的分支策略？

对于不同的情况，有什么好的吗？贵公司使用什么？它们的优点和缺点是什么？

Answer 1

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

/ trunk - 流血的边缘。下一个主要版本的代码。可能在任何特定时间都可能有效。

/branches/1.0,1.1等。代码的稳定维护分支。用于修复错误，稳定新版本。如果是维护分支，则应编译（如果适用）并准备好在任何给定时间进行质量保证/运输。如果是一个稳定分支，它应该编译并完成功能。不应添加任何新功能，不进行重构，也不需要进行代码清理。您可以添加前置前缀以指示稳定分支与维护分支。

/支链/ cool_feature。用于高度实验性或破坏性的工作，可能会或可能不会进入主干（或维护分支）。无法保证代码编译，工作或以其他方式表现得非常好。在合并到主线分支之前应该尽可能地持续最短时间。

/tags/1.0.1,1.0.2,1.1.3a等用于标记打包的＆amp;发货。永远不会改变。根据需要制作尽可能多的标签，但它们是不可变的。

Answer 2

我非常鼓励阅读Eric Sink对此事的看法：

Chapter 7: Branches

我和Eric一样，更喜欢他谈到的“文件夹”式分支。

Answer 3

关于分支模式的母亲，请参阅Brad Appleton的Streamed Lines: Branching Patterns for Parallel Software Development。这是繁重的责任，但我没有看到任何超越它的分支知识的广度和深度。

Answer 4

主动开发的一个分支（/ main或master，取决于行话）
每个维护版本的一个分支 - ＆gt;它只会收到很小的修复，而所有主要的开发都会转到/ main
每个新任务的一个分支：创建一个新分支，以处理Bugzilla / Jira / Rally上的每个新条目。经常提交，使用英寸卵石签入自行记录更改，并在完成并经过充分测试后将其合并回“父”分支。

请查看此http://codicesoftware.blogspot.com/2010/03/branching-strategies.html以获得更好的解释

Answer 5

我们的存储库看起来像：

/trunk
/branches
/sandbox
/vendor
/ccnet

/ trunk 是您标准的，前沿的发展。我们使用CI，因此必须始终构建并通过测试。

/ branches 这就是我们对'制裁'进行大规模更改的地方，也就是说，我们知道的东西会变成主干但可能需要一些工作并且会破坏CI。此外，我们在维护版本上工作，这些版本都有自己的CI项目。

/ sandbox 每个开发者都有自己的沙箱，还有一个共享的沙箱。这适用于“让我们的产品添加LINQ提供程序”这类任务，当您没有完成实际工作时。它可能最终进入主干，它可能不会，但它存在并受版本控制。这里没有CI。

/ vendor 我们编译的项目的标准供应商分支，但它不是我们维护的代码。

/ ccnet 这是我们的CI标签，只有CI服务器才能写入此处。 Hindsight会告诉我们将其重命名为更通用的内容，例如CI，BUILDS等。

Answer 6

第一件事： KISS （保持简单愚蠢！）

/branches
  /RB-1.0 (*1)
  /RB-1.1 (*1)
  /RB-2.0 (*1)
/tags
  /REL-1.0 (or whatever your version look like e.g. 1.0.0.123 *2)
  /REL-1.1
  /REL-2.0
/trunk
  current development with cool new features ;-)

* 1）保持版本可维护 - 例如服务包，修补程序，错误修正，如有必要和/或需要可以合并到主干 * 2）major.minor.build.revision

拇指规则：

无需签出Tags文件夹
发布分支中只有少数编码（使合并更简单） - 无需代码清理等。
永远不要在标签文件夹中编码
切勿将具体版本信息放入源文件中。使用占位符或0.0.0.0，构建机制将替换为您正在构建的版本号
永远不要将第三方库放入源代码控制中（也没有人会将STL，MFC等库添加到SVN; - ））
仅提交编译
首选使用环境变量而不是硬编码路径（绝对路径和相对路径）

- hfrmobile

Answer 7

我们在发布准备好进行最终质量检查时进行分支。如果在QA过程中发现任何问题，则错误将在分支中修复，验证然后合并到主干。一旦分支通过QA，我们将其标记为发布。该版本的任何修补程序也会对分支执行，验证，合并到主干，然后标记为单独的版本。

文件夹结构如下所示（1个QA行，2个修补程序版本和主干）：

/分支


/REL-1.0


/标签


/REL-1.0

/REL-1.0.1

/REL-1.0.2


/中继线

Answer 8

我们使用狂野，狂野，西方风格的git-branches。我们有一些分支机构具有按惯例定义的知名名称，但在我们的案例中，标签对我们来说实际上对于满足我们的公司流程政策要求更为重要。

我在下面看到你使用Subversion，所以我想你可能应该查看Subversion Book中有关分支的部分。具体来说，请查看Branch Maintenance和Common Branch Patterns中的“存储库布局”部分。

Answer 9

我在这里看不到的另一种选择是“改变分支”的理念。

如果行李箱是“当前版本”，那么如果不是让你的行李箱成为“狂野的西部”，那该怎么办？当只有一个版本的应用程序一次发布时（例如网站），这种方法很有效。当需要新功能或错误修复时，会建立一个分支来保存该更改。通常，这允许迁移修复程序以单独发布，并防止您的牛仔编码器意外添加要释放您不想要的功能。（通常它是一个后门 - “仅用于开发/测试”）

Ben Collins的指针非常有用，可以确定哪种风格适合您的情况。

Answer 10

Henrik Kniberg的Version Control for Multiple Agile Teams也有一些好处需要考虑。

Answer 11

Gnat写了this excellent break down关于分支策略的各种建议。

没有一个分支策略，它适用于：

您的团队规模
您的产品和生命周期
您正在使用的技术（网络，嵌入式，Windows应用）
您的源代码管理，例如Git，TFS，Hg

杰夫阿特伍德的post打破了很多可能性。另一个要添加的是促销概念（来自Ryan Duffield的链接）。在此设置中，您有一个dev分支，test bracnh和release分支。您可以升级代码，直到它到达发布分支并进行部署。

Answer 12

Jeff Atwood wrote在一篇好的博客文章中提到了这一点;该帖子中有一些重要的链接。

Answer 13

我们目前有一个分支用于持续维护，一个分支用于“新举措”，这意味着“将来某个时候出现的东西;我们不确定何时。”我们偶尔还会有两个维护分支：一个用于为当前正在生产的产品提供修复，另一个仍在质量保证中。

我们看到的主要优势是能够更快地响应用户请求和紧急情况。我们可以对生产中的分支进行修复并释放它，而不释放任何可能已经签入的额外内容。

主要缺点是我们最终在分支之间进行了大量合并，这增加了错误或合并错误的可能性。到目前为止，这不是一个问题，但绝对值得记住。

在我们制定此政策之前，我们通常在主干中进行所有开发，并且在我们发布代码时仅进行分支。然后我们根据需要修复了该分支。它更简单，但不够灵活。

Answer 14

我们在工作中遵循的理念是将行李箱保持在可以随时推动而不会对站点造成严重伤害的状态。这并不是说行李箱总是处于完美状态。当然会有错误。但重点是永远不要让它彻底崩溃。

如果您要添加功能，请分支。设计变更，分支。曾经有过很多次我想过，“哦，我可以在行李箱里做这件事，不会花那么长时间”，然后5个小时后，当我无法弄清楚那些破坏我的东西时真的希望我有分支。

当您保持行李箱清洁时，您可以快速应用并推出错误修复程序。您不必担心已经破坏的代码，您可以方便地分支。

Answer 15

对于Subversion，我同意Ryan Duffield的评论。他所提到的章节提供了对使用哪个系统的良好分析。

我问的原因是Perforce提供了一种完全不同的方式来创建SVN或CVS的分支。此外，所有DVCS都赋予它自己的分支理念。您的分支策略将取决于您使用的工具。

仅供参考，Svnmerge.py是一个协助在SVN中合并分支的工具。只要你经常使用它（每10-30次），它就能很好地工作，否则工具就会混淆。

Answer 16

无论选择哪种分支模式，您都应该尝试将分支保持为二进制树形式：

   trunk - tags
     |
    next
   /  \  \
bugfix  f1  f2
        /   \  \          
       f11    f21 f22

子节点应仅与直接父节点合并。
尽量只将整个分支与父分支合并。永远不要在分支内合并子文件夹。
只要您只合并并从整个分支中挑选，您可以在需要时挑选提交。
上图中的下一个分支仅供参考，您可能不需要它。

Answer 17

这取决于您使用的版本控制系统。每个VCS都有不同的分支方法。

你使用哪种VSC？

分支策略

17 个答案: