要分支还是不分支？

#1 楼

除非大家都在同一个工作树中工作，否则您将使用分支，无论是否调用它们。每次开发人员签入工作树时，他都会创建一个单独的本地开发分支，并且每次签入时都会进行合并。对于大多数团队而言，问题不在于是否使用分支机构，而是多少个分支以及用于什么目的？

真正进行“连续”集成的唯一方法是让每个人都在工作同一个工作树。这样，您可以立即知道您的更改是否对其他人产生不利影响。显然，这是站不住脚的。您需要在分支中进行一定程度的隔离以完成所有任务，即使该“分支”只是您的本地工作目录。我需要的是适当地平衡集成和隔离。

根据我的经验，使用更多的分支机构可以提高集成度，因为集成完全由需要完成工作的人员完成，而其他每个人可以更轻松地根据需要隔离无关的问题。例如，我花了最后一天跟踪了我们构建中最近引入的三个与集成相关的错误，这些错误阻止了我的“实际”工作。在将这些错误报告给需要修复的人员之后，我已经做了应尽的努力，现在我是否应该等到完成它们之后再继续工作？当然不是。我创建了一个临时的本地分支，用于还原这些更改，因此我可以有一个稳定的基准来工作，同时仍从上游接收最新的更改。

如果没有能力为此目的创建新分支，那么我将只能使用以下三种方法之一：还原中央存储库中的更改，手动维护将其还原到我的工作树中的补丁，并尝试避免不小心将它们检入，或返回到引入这些错误之前的版本。第一种选择可能会破坏其他依赖性。第二个选项需要大量工作，因此大多数人会选择第三个选项，这从根本上阻止了您进行更多的集成工作，直到修复了先前发现的错误为止。但相同的原则适用于共享分支。如果我共享我的分支，那么也许其他5个人能够继续执行其主要任务，而不是执行冗余的集成工作，因此总的来说，将执行更多有用的集成工作。分支和持续集成的问题不是拥有多少分支，而是合并它们的频率。

#2 楼

问题是我们现在应该使用分支吗？


大约半年前，我被分配去做研究以回答这个问题。这是摘要，是根据研究的经验总结（列出如下）



没有普遍同意的“最佳”分支策略适用于任何项目


大多数资源似乎都同意选择生产策略取决于特定的项目细节
旁注。基于以上所述，似乎需要对项目分支策略的任何更改进行测试，度量，并与测试的其他选项进行比较。所有将SVN和Git进行比较的人都指出，使用Git进行合并非常容易
，一个重要因素似乎是生产发布是源自主干还是分支。基本上禁止从主干中进行产品发布的团队（这似乎不是很流行的方法），禁止使用不稳定的主干策略。从分支执行产品发布的团队有更多分支选项可供选择。
流行的策略似乎是稳定的主干，不稳定的主干和开发（集成）分支


引用
>


http://msdn.microsoft.com/zh-cn/library/aa730834%28v=vs.80%29.aspx
...决定最好的分支策略是一种平衡行为。您必须权衡生产率的提高与风险的增加。验证所选策略的一种方法是考虑变化的情况。例如，如果您决定使分支机构与系统体系结构保持一致（例如，分支机构代表系统组件），并且期望进行重大的体系结构更改，则可能必须对分支机构以及与之相关的每次更改进行重组。选择不适当的分支策略可能会导致流程开销，冗长的集成和发布周期，这对整个团队来说都是令人沮丧的...



http://www.cmcrossroads.com/bradapp/acme/branching/
...经常，增量集成是成功的标志之一，而缺乏集成通常是失败的特征。当前的项目管理方法倾向于避免使用严格的瀑布模型，而采用类似螺旋的迭代/增量开发和渐进式交付模型。渐进式集成策略（如“合并早期和经常”及其变体）是一种风险管理形式，当有更多时间对其进行响应时，它会尝试在生命周期中较早地消除风险。 [Booch]，[McCarthy]和[McConnell]认为集成之间节奏的规律性是项目运行状况的主要指标（例如“脉冲”或“心跳”）。


早期和频繁的整合不仅可以更快地消除风险，而且可以缩小团队规模，也可以传达队友之间的变化...



http：/ /www.codinghorror.com/blog/2007/10/software-branching-and-parallel-universes.html
...在大多数源代码控制系统中，您可以创建数百个分支，而不会出现任何性能问题；这是跟踪所有您真正需要担心的分支的精神开销。分支是一个复杂的野兽。有很多分支方法，没有人能真正告诉您您做对与错的事情。




http：//www.lostechies。 com / blogs / derickbailey / archive / 2010/02/24 / branching-strategies-when-to-branch-and-merge.aspx
...分支代码时要考虑系统的许多方面...最后，目标是为编写代码的上下文提供一个沙箱。了解可用选项，何时每个选项最适合当前情况以及这些选项的成本将帮助您确定分支方式和时间...

http：//www.snuffybear .com / ucm_branch.htm
注意这里给出的其他参考，作者声称“本文描述了软件工程项目中使用的三个关键分支模型”似乎没有道理。使用的术语看起来并不广泛（EFIX，Model 1,2、3等）。
http://svn.haxx.se/users/archive-2007-10/att-0101/SCMBranchingModels-talkback.pdf
参考文献提供了一个有趣的例子，说明了沟通分支策略的困难。

http://simpleprogrammer.com/2010/06/04/simple-branching-strategy-part-1-back-to -basics /
...保持简单。在我看来，直接在外线工作是最好的方法。


当我在屏幕上实际键入时，听起来几乎像是异端，但是如果您愿意的话，一会儿，我不仅会向您展示为什么我认为这对于敏捷流程至关重要，而且还将向您展示如何使其发挥作用...


...如果我必须以一个可靠的论据为基础，这就是持续整合的价值。过去，我在博客中介绍了CI的价值和最佳实践。我是CI的忠实拥护者。


...您真的必须在这里问自己一个问题：“难道这就是您进行复杂分支所产生的所有开销，合并策略所产生的实际价值不存在于更简单的策略上？” ...


...我过去有效使用并随着时间而发展的策略。我在这里简单地总结一下。



每个人都可以下车。
发布代码时分支。
当您需要为已发布的代码创建错误修复程序时，请分支该版本。
原型的分支。
...



http://simpleprogrammer.com/2010/06/07/simple-branching-strategy -part-2-implementation /
...相当详细的演练...




http：//www.codelathe。 com / blog / index.php / 2009/07/02 / a-svn-branching-strategy-that-works /
...最后，请记住，没有理想的分支和合并策略。这在很大程度上取决于您独特的开发环境...

http://blog.perforce.com/blog/?cat=62
...最坏的情况是您引入了“语义合并”问题，其中自动合并的结果不正确，但编译正常并偷偷通过了测试，甚至可能存活足够长的时间才能成为客户可见的错误。 Eek！
改变。 （通常最好是在进行更改后立即合并更改，如果可行，最好由发起更改的开发人员合并）...



http：//blog.perforce .com / blog /？p = 1635
注意，由于http://www.infoq.com/articles/agile-version-control#q11和http：// msdn.microsoft.com/zh-cn/library/bb668955.aspx

促销模型说明：http://www.perforce.com/perforce/papers/life.html




https://stackoverflow.com/questions/34975/branching-strategies
社区成员在使用不同分支策略的各个项目中分享不同的经验。对于“最佳”或“最坏”，没有达成共识。经典”阅读-解释了诸如Mainline Model，Codeline等之类的术语



http://www.stickyminds.com/s.asp?F=S16454_COL_2
本质上http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf




http://www.stickyminds.com/ s.asp？F = S16511_COL_2
...确定何时以及如何分支的三种常见方法：



当您“功能已完成”时，请创建发布分支，并计划解决此代码行上的最新问题。在这种情况下，发布分支实际上是“发布准备代码行”，如软件配置管理模式中所述，因为您希望仍有工作要做。
更改工作方式以避免最终集成工作，从活动开发线开始工作。
通过创建任务分支并在发布完成后将工作合并到活动开发线中，为新工作创建分支。
...分支的原理是在发布结束时隔离代码，以使其稳定。通过分支隔离通常掩盖了质量问题，最终会在产品发布之前以维护并行流的额外成本体现出来。分支很容易。相反，这是了解困难之间分支之间的变化流向的合并和认知开销，因此选择一个使分支和合并成本最小化的过程很重要...






http://nvie.com/posts/a-successful-git-branching-model/面向Git的策略。
...是HEAD源代码始终反映生产就绪状态的主要分支。


我们认为origin / develop是HEAD源代码始终反映状态的主要分支以及下一版本的最新交付开发更改。有人将其称为“集成分支”。这是构建任何夜间自动构建的地方。...


与http://www.infoq.com/articles/agile-version- control＃q11和http://msdn.microsoft.com/zh-cn/library/bb668955.aspx



http://svnbook.red-bean.com /en/1.5/svn.branchmerge.html
...关于何时合适创建功能分支的项目政策差异很大。一些项目根本不使用功能分支：提交/ trunk是免费的。该系统的优点是它很简单-无需学习分支或合并的知识。缺点是中继代码通常不稳定或不可用。其他项目则极端使用分支：没有更改直接提交给主干。即使是最琐碎的更改，也会在短暂的分支上创建，仔细检查并合并到主干中。然后删除该分支。该系统可确保始终具有异常稳定且可用的中继线，但以巨大的过程开销为代价。他们通常坚持要求/ trunk始终编译并通过回归测试。仅当更改需要大量破坏稳定的提交时才需要功能分支。一个很好的经验法则是问这个问题：如果开发人员孤立地工作了几天，然后一次全部提交了大的更改（这样/ trunk就不会变得不稳定），那么更改是否太大以至于无法审查？如果对该问题的答案为“是”，则应在功能分支上进行更改。当开发人员将增量更改提交到分支时，同行可以轻松地对其进行检查。随着工作的进展。如前所述，在分支机构工作数周或数月存在很大的风险。树干的变化可能会继续涌入，以至于两条发展线的差异如此之大，以至于试图将分支合并回到树干中可能成为一场噩梦。
最好通过定期将主干更改合并到分支来避免这种情况。制定政策：每周一次，将上周的主干更改值合并到分支机构...

http://thedesignspace.net/MT2archives/000680.html
... Eclipse CVS教程的这一部分是基于Paul Glezen在Eclipse网站上的文章：与Eclipse和CVS分支，并在他的许可下使用根据EPL许可的条款。我对他的版本所做的更改主要是为了逐步扩展它，并提供更多逐步的图像和说明，并将其与我自己的初学者教程集成在一起，以使初学者和设计师可以更容易地使用它。经验丰富的开发人员可能更喜欢从Paul版本开始工作...


http://www.eclipse.org/articles/article.php?file=Article-BranchingWithEclipseAndCVS/article1.html
http://www.eclipse.org/articles/article.php?file=Article-BranchingWithEclipseAndCVS/article2.html



http：// learnsoftwareprocesses .com / 2007/12/29 / common-branching-strategies /
...以下是一些常见的分支模型：





按发布分支模式：最常见的分支策略之一是使分支与产品发布保持一致。分支机构拥有单个发行版的所有软件开发资产。有时，更新需要从一个发行版合并到另一个发行版，但是它们通常永远不会合并。

每个升级的分支：另一个非常普遍的方法是使分支与软件资产升级级别保持一致。特定的开发版本被分支到Test分支，在该分支上执行所有集成和系统测试。完成测试后，软件开发资产将分支到Production分支中，并最终进行部署。

每个任务的分支：为避免任务（或活动）重叠和生产率下降，可以将它们隔离在单独的分支上。请记住，这些是短期分支，应在任务完成后立即将其合并，否则，所需的合并工作可能会超出首先创建它们的生产率所带来的好处。
<分支每个组件：您可以使每个分支与系统架构保持一致。在此策略中，您将分支各个组件（或子系统）。然后，每个开发组件的团队都决定何时将其代码重新合并到用作集成分支的开发线中。如果系统架构适当并且各个组件具有定义明确的接口，则此策略可以很好地发挥作用。您在分支上开发组件的事实使您可以对软件开发资产进行更精细的控制。

每个技术的分支：与系统体系结构保持一致的另一种分支策略。在这种情况下，分支与技术平台保持一致。通用代码在单独的分支上进行管理。由于分支机构上管理的软件开发资产的独特性，它们可能永远不会合并...



http://msdn.microsoft.com/zh- us / library / bb668955.aspx
...有关分支和合并指南的摘要，请参阅本指南“源代码控制指南”中的分支和合并指南。
...分支时，请考虑以下内容：



不要分支，除非您的开发团队需要同时处理同一组文件。如果不确定，可以在以后标记该构建并从该构建创建分支。合并分支可能非常耗时且复杂，特别是如果它们之间有重大更改。
构造分支树，以便只需要沿着层次结构（分支树上下）进行合并，而无需跨层次结构进行合并。跨层次结构分支需要使用无基础合并，这需要更多的手动冲突解决方法。
分支层次结构基于分支父级和分支子级，这可能与磁盘上源代码的物理结构不同。规划合并时，请记住逻辑分支结构而不是磁盘上的物理结构。
不要分支得太深。因为执行每个合并和解决冲突需要时间，所以深层的分支结构可能意味着子分支中的更改可能需要很长时间才能传播到主分支。这可能会对项目进度产生负面影响，并增加修复错误的时间。
进行高层分支，并包括配置文件和源文件。
随着时间的推移发展分支结构。
合并需要一个或多个更多开发人员执行合并并解决冲突。合并的源必须经过彻底的测试，因为做出错误的合并决定可能会破坏构建的稳定性并不少见。
跨分支层次结构的合并特别困难，并且需要您手动处理许多本可以自动处理的冲突。

可以将是否创建分支的决定减少为实时合并冲突的成本是否高于分支之间合并冲突的开销成本...



http://kashfarooq.wordpress.com/2009/11/23/bazaar-branching-strategy-with-a-subversion-trunk/


http://kashfarooq.wordpress.com/2010/12/16/bazaar-branching-strategy-with-a-subversion-trunk-revised/
http://kashfarooq.wordpress.com/2009/11/ 02 / using-bazaar-feature-branches-with-a-subversion-trunk /

http://kashfarooq.wordpress.com/2009/09/08/bazaar-or-git-moving-远离颠覆/
...这些Subversion投诉中的任何一个听起来很熟悉吗？


您会被随机告知“您需要运行更新”。然后，您进行更新-需要一些时间才能完成。然后，最后，您看到不需要下载任何更改。
您被随机提示“您需要运行清理”。
您遇到了很大的合并问题。例如，您使用ReSharper重命名一个类，与此同时其他一些更新了该类。然后，您会看到可怕的树冲突错误（颤抖）。甚至更糟的是，您重命名了整个名称空间和文件夹（双颤抖）。现在您的确陷入了一个痛苦的世界。
您的合并通常会越来越手动。您经常需要使用WinMerge，因为Subversion毫无头绪。
您经常在等待Tortoise更新/检查修改/任何内容。


我有一个我的USB笔式驱动器上的subversion存储库。我遇到树冲突并合并问题，并且是唯一的用户！


主要问题是合并...




“颠覆很烂”听起来很耳熟。是时候听Joel和Linus了吗？


http://social.msdn.microsoft.com/Forums/en/tfsversioncontrol/thread/f127676c-8f05-410c-9a30-0eb43a26a9fa
讨论在不断发展的系统中发布隔离分支策略的最佳实践。
http://branchingguidance.codeplex.com/
“ Microsoft Team Foundation Server分支指南”-庞大而详细文档以及针对不同项目的建议：此处为HTML版本。证明Microsoft不相信一种适用于所有方法的分支策略。
-integration
要进行连续集成时，最佳的分支策略是什么？
...答案取决于您的团队规模和源代码管理的质量以及正确合并复杂变更集的能力...




http：// www.zeroturnaround.com/blog/continuous-integration-and-feature-branches/
，基于Hudson / Jenkins的具体经验，结合分支参考，并结合了一些有用的参考资料，从而更详细地分析了分支与连续集成的相互作用。 /> ...我的最大发现是，尽管CI经常涉及提交，推送和获取反馈（即CI集群为您提供了工作站无法在相同的时间内提供给您的反馈），但真正的纯粹CI还有一个要求-团队需要在相同的基准上工作...使用的材料




多个分支的最佳实践–发布到Jenkins列表

是否可以处理多个分支，其中一些作业应在每个分支上运行而无需重复–发布到Jenkins列表
与分支的并行开发–发布到Jenkins列表

自动配置或创建Hudson作业– stackoverflow.com

与多个分支开发的持续集成– stackoverflow.com

在持续集成中处理多个分支– stackoverflow.com
持续集成– Martin Fowler

持续集成–维基百科





http://codicesoftware.blogspot.com/2010/03/branching-strategies.html
... CVS和SVN阻止了整个分支/合并策略，因为它们完全无法做到这一点...
...简单的规则：为您要实现的每个新功能或错误修正创建一个任务分支...对于SVN / CVS用户来说听起来有些过头，但您知道任何现代的SCM都可以在一秒钟内创建分支，因此没有真正的开销。


重要说明：如果仔细看，您会发现我正在谈论使用任务分支作为富人变更列表...
http://publib.boulder.ibm.com/infocenter/cchelp/ v7r0m1 / index.jsp？topic = / com.ibm.rational.clearcase.cc_proj.doc / c_bntr_plnbrstrat.htm
...分支策略受项目开发目标的影响，并提供了控制演化的机制代码库分支策略的变化与使用Rational ClearCase版本控制的组织一样多。但是也有一些相似之处，反映出对最佳实践的普遍遵守...
http://blogs.open.collab.net/svn/2007/11/branching-strat.html
...颠覆模型（或更准确地说是通用开源模型）就是不稳定主干模型中显示的内容。
http://en.wikipedia.org/wiki/Trunk_%28software%29
在在软件开发领域，主干是指受修订控制的文件树的未命名分支（版本）。通常，主干是开发进行的项目的基础。如果开发人员专门在主干上工作，则它始终包含项目的最新尖端版本，因此也可能是最不稳定的版本。另一种方法是将分支从主干中分离出来，在该分支中执行更改，然后在分支被证明稳定且可以正常工作时将更改合并回主干。根据开发模式和提交策略，主干可能包含最稳定或最不稳定的版本或介于两者之间的版本。


通常主要的开发人员工作都在主干和稳定版本中进行。分支，偶尔的错误修复从分支合并到主干。当在非主干分支中完成将来版本的开发时，通常是针对不经常更改的项目完成的，或者是预期更改需要很长时间才能开发的项目，直到准备好将其合并到主干中。 。
http://www.mcqueeney.com/roller/page/tom/20060919
...这些是CollabNet于2006年8月30日举办的有关Subversion最佳实践的网络研讨会的记录。 。两种组织策略：不稳定的主干vs.稳定的主干...
...在可能的情况下优先选择不稳定的主干...

https://stackoverflow.com/questions/153812/ subversion是最主要的主要开发场所
在SVN中，trunk是主要开发的推荐场所，我在所有项目中都使用了这个约定。但是，这意味着主干有时不稳定，甚至坏了...
...最好不要在/ branch / dev之类的分支上进行“野生开发”，并且仅在出现以下情况时合并到主干建造合理吗？



...主干是应该进行持续开发的地方。如果每个人都在提交更改之前测试他们的更改，那么您实际上应该对“中断”的代码没有问题。一个好的经验法则是在对更改进行编码后进行更新（从存储库中获取所有最新代码）。然后构建并进行一些单元测试。如果一切正常，您应该检查一下...
...行李箱不是最好的地方。在我们的组织中，我们始终遵循这种方法：Trunk包含发行代码，因此它总是可以编译。有了新的每个发行版/里程碑，我们将打开一个新分支。每当开发人员拥有一个项目时，他/她都会为该发行分支创建一个新分支，并且仅在对其进行测试之后将其合并到发行分支中。在系统测试之后，版本分支合并到了主干中。

http://blog.yclian.com/2009/03/working-on-branches-and-stable-trunk。 html
...我以前在主干上工作，因为对于我从事的所有项目，要么我是唯一的开发人员，要么团队要确保每个代码签入都通过本地测试。否则，我们（仍然）会创建分支来修复错误，为新功能提供大代码等。


大约2个月前，我与Kamal进行了简短的git会话，他与我分享了故事/分支的想法。随着我的团队开始与更多开发人员一起成长，我感到有必要鼓励更多的分支机构，现在这已成为规则。对于使用CI设置定义了自动化测试的项目，可以保证稳定的主干，并且这种做法非常适合。


我们不使用git而是Subversion，因为这就是我们开始了，现在（大多数时间）我们仍然对此感到满意...
http://www.ericsink.com/scm/scm_branches.html

这是一本名为Source Control HOWTO的在线书籍，这是有关源代码控制，版本控制和配置管理的最佳做法指南...


... Eric的首选分支机构实践...保持“基本上不稳定”的树干。在主干中进行积极的开发，随着发布的临近​​，主干的稳定性会提高。发货后，创建一个维护分支，并使其始终保持稳定...


...在下一章中，我将深入探讨合并分支的主题...

http://marc.info/?l=forrest-dev&m=112504297928196&w=2
开始讨论Apache Forrest项目分支策略的线程邮件


注意目前该项目似乎使用带有发行分支的不稳定主干模型： （项目准则）
“正在构建候选发布程序包... 17.在SVN中创建维护分支...”（如何发布）



O'Reilly CVS分支文档：http：//commons.oreilly.com/wiki/index.php/Essential_CVS/Using_CVS/Tagging_and_Branching#Basically_stable



...基本稳定的分支哲学指出，主干应包含始终准备好发布的项目数据...
...更多这种哲学的宽大变化允许通过开发人员单元测试的所有内容都合并到主干中。这种宽松的方法要求分支发布候选者，并在发布之前进行完整的QA分析...
...基本上不稳定的哲学认为，主干应包含最新代码，而不论其稳定性如何，


...更多宽大的变体也允许分支用于实验代码，重构和其他特殊情况的代码。将分支合并回主干是由分支的管理者完成的。 ...


注意上面的资源没有出现在我执行的任何搜索中（与CVS相关的准则不再流行了吗？）




SCM最佳实践（perforce文章），网址为http://www.perforce.com/perforce/papers/bestpractices.html
... SCM部署的六个一般领域，以及一些这些领域中每个领域的最佳实践。以下各章介绍了每个项目...工作区，代码行，分支，更改传播，构建，过程...

评论

---

我相信这是我在任何stackexchange问​​题中看到的最长答案！

–约翰·费舍尔
2011-09-14 17:45

---

@JohnFisher很好，根据JIRA，那时我花了6个小时来整理和总结这些参考文献：）

– gna
2011-09-15 6:34

---

您缺少某种摘要，该摘要应告诉您是否对新功能使用新分支。您的答案只是各种文章的链接的总和-有些文章讲的是一回事，而其他文章讲的则相反。您的答案很长，所以我可能迷路了。

–BЈовић
2014年1月8日在9:46

---

答案的开头提供了@BЈовић的摘要：'没有公认的适用于任何项目的“最佳”分支策略。 *大多数资源似乎都同意选择生产策略取决于特定的项目细节

– gna
2014年1月8日12:20

---

补充阅读：谷歌与Facebook的基于主干的开发“他们[谷歌和Facebook]没有合并的痛苦，因为通常开发人员不与分支机构进行合并。至少在中央仓库的服务器之间，它们不是合并的。 ，开发人员可能会与本​​地分支机构进行合并，并在将“完成”的事情推送回中央仓库时重新定级……”

– gna
2014年1月14日10:22

---