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

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

解决方案

回答

我强烈鼓励我们阅读Eric Sink关于此事的观点：

第7章分支机构

我和Eric一样，更喜欢他谈论的"文件夹"样式分支。

回答

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

我们使用哪个VSC？

回答

我们目前有一个分支机构进行日常维护，一个分支机构则负责"新计划"，这仅意味着"将来会出现某种东西；我们不确定何时。"有时我们还会有两个维护分支：一个是为当前生产中的问题提供修复，另一个是仍在质量保证中。

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

主要缺点是我们最终会在分支之间进行大量合并，这增加了某些内容被错误遗漏或者合并的机会。到目前为止，这还不是问题，但是绝对要牢记。

在制定这项政策之前，我们通常会在主干中进行所有开发，并且只有在发布代码时才分支。然后，我们根据需要针对该分支进行了修复。它比较简单，但没有那么灵活。

回答

我们在工作中遵循的理念是将行李箱保持在可以随时推入的状态，而不会对现场造成重大伤害。这并不是说行李箱将始终处于完美状态。当然会有错误。但关键是永远不要彻底破坏它。

如果我们要添加功能，请分支。设计更改，分支。我曾想过很多次，"哦，我可以在后备箱中做这件事，用不了那么长时间"，然后5个小时后，当我无法弄清破坏事物的错误时，真希望我分支了。

当我们保持后备箱清洁时，可以有机会快速应用并推出错误修复程序。我们不必担心自己的分支代码容易破损。

回答

对于Subversion，我同意Ryan Duffield的评论。他所指的这一章对使用哪种系统进行了很好的分析。

我问的原因是Perforce提供了一种完全不同的方法来从SVN或者CVS创建分支。另外，所有DVCS都提供了自己的分支哲学。分支策略将由我们使用的工具决定。

仅供参考，Svnmerge.py是协助合并SVN中分支的工具。只要我们经常使用它(每10-30次)提交一次，它就可以很好地工作，否则该工具可能会感到困惑。

回答

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

文件夹结构如下所示(1个质量检查行，2个修补程序版本和主干)：

/branches
  
  
    /REL-1.0

/标签

/REL-1.0
    
    /REL-1.0.1
    
    /REL-1.0.2

/树干

回答

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

/ trunk出血边缘。该代码的下一个主要版本。在任何给定时间可能有效或者可能无效。

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

/分支机构/ cool_feature。用于可能会也可能不会进入主干(或者维护分支)的高度实验性或者破坏性工作。不保证有关代码的编译，正常运行或者其他行为。在合并到主线分支之前，应尽可能保持最短的时间。

/tags/1.0.1、1.0.2、1.1.3a等。用于标记打包和出厂的发行版。永远都不会改变。制作任意数量的标签，但它们是不可变的。

回答

我们使用git-branchs的狂野，狂野，西方风格。我们有一些分支机构具有按惯例定义的众所周知的名称，但是在我们的情况下，标签实际上对于我们满足公司流程策略要求而言更为重要。

我在下面看到我们使用Subversion，所以我想我们可能应该查看Subversion手册中有关分支的部分。具体来说，请查看"分支机构维护"和"通用分支模式"中的"存储库布局"部分。

回答

我们的存储库如下所示：

/trunk
/branches
/sandbox
/vendor
/ccnet

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

/分支这是我们批准的大型更改的地方，即我们知道的某些内容将使更改成为主要内容，但可能需要做一些工作并且会破坏CI。也是我们维护维护版本的地方，维护维护版本具有自己的CI项目。

/ sandbox每个开发人员都有自己的沙箱，以及一个共享的沙箱。这是针对我们在不执行实际工作时执行的"让我们在产品中添加LINQ提供程序"这类任务。它可能最终会进入主干，可能不会，但是它在那里并且受版本控制。这里没有CI。

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

/ ccnet这是我们的CI标记，只有CI服务器可以在此处写入。 Hindsight会告诉我们将其重命名为更通用的名称，例如CI，BUILDS等。

回答

我在这里没有看到的替代方法是"变革分支"的哲学。

如果后备箱是"当前发行版"，该怎么办，而不是将后备箱设置为"狂野西部"呢？当一次仅发布一个版本的应用程序(例如网站)时，此方法效果很好。当需要新功能或者错误修复时，将创建一个分支来保存该更改。通常，这允许将修补程序迁移到各个版本，并防止牛仔编码人员意外添加我们不想要的功能。 (通常是后门"仅用于开发/测试")

Ben Collins的指针在确定哪种样式适合情况时非常有用。

回答

Henrik Kniberg的多个敏捷团队的版本控制也有一些需要考虑的方面。

回答

有关分支模式的信息，请参见Brad Appleton的"流线：并行软件开发的分支模式"。这是繁重的工作，但就分支的广度和深度而言，我还没有发现任何可以超越它的东西。

回答

杰夫·阿特伍德(Jeff Atwood)在一篇不错的博客文章中写道。该帖子中有一些重要链接。

回答

• 一个分支用于主动开发(/ main或者master，取决于术语)
• 每个维护版本都有一个分支->它只会收到很小的修正，而所有主要开发都移至/ main
• 每个新任务的一个分支：创建一个新分支，以处理Bugzilla / Jira / Rally上的每个新条目。经常提交，使用英寸的卵石签入文件自行记录更改，并仅在完成并经过良好测试后将其合并回其"父"分支。

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

回答

无论选择哪种分支模式，都应尝试将分支保持为二叉树形式，如下所示：

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

• 子节点只能与直接父节点合并。
• 尽最大努力将整个分支与父分支合并。切勿在分支内合并子文件夹。
• 只要我们仅合并并从整个分支中进行选择，就可以在需要时选择提交。
• 上图中的下一个分支仅用于说明，我们可能不需要它。