要分支还是不分支？

直到最近，我的开发工作流程如下：

1. 从产品所有者那里获得功能
2. 进行分支（如果功能超过1天）
3. 在分支中实施
4. 合并从主分支到我的分支的更改（以减少向后合并期间的冲突）
5. 合并我的分支回到主分支

有时合并存在问题，但总的来说，我喜欢它。

但是最近，我看到越来越多的想法的追随者不要建立分支机构，因为这使得实践连续集成，连续交付等变得更加困难。对于具有分布式VCS背景的人们，他们在谈论如此大的合并实现时尤其有趣。 Git，Mercurial等

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

除非你都工作了相同的工作树，你正在使用的分支，无论你叫他们或没有。每次开发人员签入工作树时，他都会创建一个单独的本地开发分支，并且每次签入时都会进行合并。对于大多数球队，问题不在于如果您使用分支机构，问题是多少和目的是什么？

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

以我的经验，使用更多的分支机构可以提高集成度，因为集成完全由需要完成的人员完成，其他所有人都可以根据需要更轻松地隔离无关的问题。

例如，我用了最后一天来追踪构建中最近引入的三个与集成相关的错误，这些错误阻止了我的“实际”工作。在尽我所能将错误报告给需要修复的人员之后，我现在是否应该等待它们完成以继续工作？当然不是。我创建了一个临时的本地分支来还原这些更改，因此我可以有一个稳定的基准来工作，同时仍从上游接收最新的更改。

如果没有能力为此目的创建新分支，那么我将只能使用以下三种方法之一：还原中央存储库中的更改，手动维护将其还原到我的工作树中的补丁，并尝试避免不小心将它们检入，或返回到引入这些错误之前的版本。第一种选择可能会破坏其他依赖性。第二个选项需要大量工作，因此大多数人会选择第三个选项，这实际上会阻止您进行更多的集成工作，直到修复先前发现的错误为止。

我的示例使用了私有本地分支，但是相同的原理也适用于共享分支。如果我共享我的分支，那么也许其他5个人能够继续执行其主要任务，而不是执行冗余的集成工作，因此总的来说，将执行更多有用的集成工作。分支和持续集成的问题不是您拥有多少分支，而是合并它们的频率。

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

大约半年前，我被分配去做研究以回答这个问题。这是摘要，根据研究的参考文献（以下列出）

• 没有适用于任何项目的公认的“最佳”分支策略
  • 大多数资源似乎都同意选择生产策略取决于特定的项目细节
  • 边注。基于以上内容，看来项目分支策略的任何更改都需要测试，衡量并与其他测试选项进行比较
• 流行的观点是与Subversion合并需要付出很多努力。所有比较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，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
  ...最坏的情况是您引入了“语义合并”问题，其中自动合并的结果不正确，但编译正常并潜行了测试，甚至可能存活足够长的时间才能成为客户可见的错误。ek！  
   
  由于侮辱可以更长久地逃避检测，因此增加了伤害，因为语义更改问题在发起更改的开发人员的脑海中不再新鲜，因此以后很难修复。（通常最好是在更改完成后立即合并更改，如果可行，最好由发起更改的开发人员合并）...

  • 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
  社区成员在使用不同分支策略的各种项目中分享不同的经验。没有关于“最佳”或“最差”的共识。

  • http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf
    “经典”阅读-解释了诸如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的策略。
  ...我们认为Origin / master是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/zh-CN/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/
  ...以下是一些常见的分支模型：  

  1. 按发布分支模式：最常见的分支策略之一是使分支与产品发布保持一致。分支机构拥有单个发行版的所有软件开发资产。有时，更新需要从一个发行版合并到另一个发行版，但它们通常永远不会合并。发行版停用后，分支将终止。  
  2. 每个促销的分支：另一种非常普遍的方法是使分支与软件资产促销级别保持一致。特定的开发版本被分支到Test分支，在该分支上执行所有集成和系统测试。完成测试后，软件开发资产将分支到生产分支中，并最终进行部署。  
  3. 每个任务的分支：为避免任务（或活动）重叠和生产率下降，可以将它们隔离在单独的分支上。请记住，这些是短期分支，应在任务完成后立即合并，否则，所需的合并工作可能会超出首先创建它们的生产率带来的好处。  
  4. 每个组件的分支：您可以使每个分支与系统架构保持一致。在此策略中，您将分支各个组件（或子系统）。然后，每个开发组件的团队都决定何时将其代码重新合并到用作集成分支的开发线中。如果系统架构适当并且各个组件具有定义明确的接口，则此策略可以很好地发挥作用。您在分支机构上开发组件的事实使您可以更精细地控制软件开发资产。  
  5. 每种技术的分支：与系统体系结构保持一致的另一种分支策略。在这种情况下，分支与技术平台保持一致。通用代码在单独的分支上进行管理。由于分支机构管理的软件开发资产的独特性，它们可能永远不会合并...

• http://msdn.microsoft.com/zh-cn/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-away-from-subversion/
    ...这些Subversion投诉听起来是否很熟悉？
    • 系统会随机提示您“您需要运行更新”。然后，您进行更新-需要一些时间才能完成。然后，最后，您看到不需要下载任何更改。
    • 系统会随机提示您“您需要运行清理”。
    • 您有巨大的合并问题。例如，您使用ReSharper重命名一个类，与此同时其他一些人对该类进行了更新。然后，您将看到可怕的树冲突错误（颤抖）。甚至更糟的是，您将整个命名空间和文件夹重命名（双颤抖）。现在，您的确陷入了痛苦的世界。
    • 您的合并往往越来越手动。您经常必须使用WinMerge，因为Subversion毫无头绪。
    • 您经常在等待Tortoise更新/检查修改/任何内容。  
       
      我的USB笔式驱动器上有一个Subversion存储库。我遇到树冲突并合并问题，并且我是唯一的用户！  
       
      主要问题是合并...  
       
  • “颠覆糟透了”听起来很耳熟。是时候听乔尔和莱纳斯了吗？

• http://social.msdn.microsoft.com/Forums/en/tfsversioncontrol/thread/f127676c-8f05-410c-9a30-0eb43a26a9fa
  讨论了在不断发展的系统中发布隔离分支策略的最佳实践。

• http://branchingguidance.codeplex.com/
  “ Microsoft Team Foundation Server分支指南”-庞大而详细的文档，其中包含针对不同项目量身定制的建议：此处为HTML版本。证明Microsoft不相信一种适用于所有方法的分支策略。

• https://stackoverflow.com/questions/597707/best-branching-strategy-when-doing-continuous-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
  ... Subversion模型（或更准确地说是一般的开源模型）正在不稳定的主干模型中显示。 。

• http://en.wikipedia.org/wiki/Trunk_%28software%29
  在软件开发领域，Trunk指的是受修订控制的文件树的未命名分支（版本）。通常，主干是开发进行的项目的基础。如果开发人员专门在主干上工作，则它始终包含项目的最新尖端版本，因此也可能是最不稳定的版本。另一种方法是将分支从主干中分离出来，在该分支中实施更改，然后在分支被证明稳定且可以正常工作时将更改合并回主干中。取决于开发模式和提交中继可能包含最稳定或最不稳定的版本或介于两者之间的版本。  
   
  通常，主要的开发人员工作会在主干中进行，稳定版本会分支，偶尔的错误修复会从分支合并到主干中。当在非主干分支中完成将来版本的开发时，通常是针对不经常更改的项目完成的，或者是预期更改需要很长时间才能开发的项目，直到准备好将其合并到主干中。 。

• http://www.mcqueeney.com/roller/page/tom/20060919
  ...这些是CollabNet于2006年8月30日举行的有关Subversion最佳实践的网络研讨会的记录。...两种组织策略：不稳定的主干vs.稳定的主干... ...尽可能地选择不稳定的主干...

• https://stackoverflow.com/questions/153812/subversion-is-trunk-really-the-best-place-for-the-main-development
  在SVN中，trunk是主要开发的推荐位置，我使用此约定对于我所有的项目。但是，这意味着主干有时会不稳定，甚至坏了……...最好不要在/ branch / dev等分支上进行“狂野开发”，而仅在合理构建时合并到主干。固体？

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

• http://blog.yclian.com/2009/03/working-on-branches-and-stable-trunk.html
  ...我以前在树干上工作，因为对于我从事的所有项目，要么是唯一的开发人员或团队应确保每个代码签入都通过本地测试。否则，我们（仍然）会创建分支来修复错误，为新功能提供大代码等。  
   
  大约2个月前，我与Kamal进行了简短的git会话，他与我分享了story / branch的想法。随着我的团队开始与更多开发人员一起成长，我感到有必要鼓励更多的分支机构，现在这已成为规则。对于具有通过CI设置定义的自动化测试的项目，可以保证稳定的中继线，并且这种做法非常适合。  
   
  我们不使用git，而是使用Subversion，因为这是我们的开始方式，我们现在（大部分时间）仍然对它感到满意...

• http://www.ericsink.com/scm/scm_branches.html
  这是一本名为Source Control HOWTO的在线书籍的一部分，这是有关源代码管理，版本控制和配置管理的最佳实践指南...  
   
  ... Eric的Preferred Branching练习...保持“基本不稳定”的后备箱。在主干中进行积极的开发，随着发布的临近​​，主干的稳定性会提高。发货后，创建一个维护分支，并使其始终保持稳定  
   
  ...在下一章中，我将深入探讨合并分支的主题...

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

  • 注意当前该项目似乎使用带有发行分支的不稳定主干模型：
  • “开发工作是在SVN的主干上完成的。有SVN的“发布分支”，例如forrest_07_branch。” （项目准则）
  • “正在构建候选发布程序包... 17.在SVN中创建维护分支...”（如何发布）

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

  • ...基本稳定的分支哲学说，主干应该包含总是准备好发布的项目数据... ...这种哲学的宽大变化允许通过开发人员单元测试的任何内容合并到树干。这种宽松的方法要求分支发布候选版本，并在发布之前进行完整的质量检查分析。
  • ……基本上不稳定的哲学认为，主干应该包含最新的代码，而不管其是否稳定，并且应该将候选版本分支出来进行质量检查。
     
     
    ...更多宽大的变体还允许分支用于实验代码，重构和其他特殊情况的代码。将分支合并回主干是由分支的管理者完成的。...
    • 注意上面的资源没有出现在我执行的任何搜索中（与CVS相关的准则不再流行了吗？）

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

如果您有多个团队同时处理不同的功能，则无法忽略分支。您应该与团队成员共享（部分实现）代码，以防止其他团队获得未完成的功能。

分支是实现这一目标的最简单方法。

尽管缩短分支的生命周期并避免同时在两个分支中使用相同的模块是一件好事-这样您就不会有冲突/合并问题。

但是最近我看到越来越多的想法追随者不要建立分支机构，因为实践连续集成，持续交付等变得更加困难。

那么为您具体实施连续集成，连续交付等会增加难度吗？

如果没有，我认为没有理由改变您的工作方式。

当然，遵循当前情况以及当前最佳做法的发展是一个好的做法。但是我不认为我们需要放弃我们的流程/工具/不只是因为X（和/或Y和/或Z）表示它们不再流行：-)

一组有趣的答案。在过去20多年的时间里，我从未在一家公司中使用过很多琐碎的分支工作（通常只是分支发布）。

我工作过的大多数地方都依赖相当快的签入和快速检测/解决冲突的能力-敏捷方法论教您，如果在双方都在积极思考该段代码的同时注意到这些问题，则可以更快地解决问题。

另一方面，我没有使用过git，也许是git标签的加入影响了这些答案-我知道git是给定的分支/合并，因为它很容易。

是的，您应该使用分支来隔离（至少中等）开发工作。请参阅“ 您应该何时分支？ ”。

问题更多是使用快进合并（包括另一个分支中的分支历史记录），前提是您首先压缩了所有“中间检查点提交”（在回滚或情况下可能会出现问题git bisect）。
请参阅“ 了解Git工作流程 ”，以区分私有分支（不希望被推送）与公共分支，这将由ff合并（快进合并）完成，前提是您要在合并的分支内进行必要的清理。
另请参见“ 为什么git默认使用快速转发合并？ ”。

您绝对应该使用分支。有许多优点。

• 如果您担心由于高清故障，笔记本电脑丢失等原因而导致工作松懈，并且不会破坏主配置项，则可以随时随地检查工作。
• 您仍然可以执行配置项，只需设置自己的本地配置项来监视分支。
• 如果功能突然被搁置（永远不会发生），则可以将其停放。

太辛苦绝不是借口。始终需要付出更多的努力才能做到正确。

如果两个团队在各自的分支机构工作，那么即使两个团队都集成了该master分支机构，他们也不会看到另一个团队的更改。这意味着他们的开发部门将错位，如果其中一个团队将与合并master，则另一个团队必须重新调整很多基础。

因此，即使您具有功能的分支，我还是敦促您将所有重构的“反向移植”到主分支，并仅将分支保留用于新功能。

• 反向移植重构

我认为，有时使用功能开关来禁用尚未投入生产的未经测试的新功能可能会更容易。这样，其他所有团队都将看到这些变化，而不必进行大的合并。

• 使用功能开关

我们再次经历了此过程。首先，我们进行了整个GIT / SVN辩论，这使我们总体上进入了分支策略。

较大的公司都使用基于主干的策略，每个人都在同一分支机构工作，并且从该分支机构进行构建和持续集成。使用代码模块化，功能切换和巧妙的工具可以避免冲突。这听起来很难..因为确实如此。但是，如果您要进行这场辩论，那是因为您已经成为人们幻想分支的受害者。有人声称他们在这里使用具有完全符合sarbanes-oxley标准的促销分支机制的insert SCM工具，这一切都很出色。他们要么撒谎，自欺欺人，要么不在与您同样规模的系统上工作。

分支和合并很难。特别是如果您的业务定期改变主意并要求回滚等。

这句话可以挽救您的生命： SCM中的内容与您构建的工件中的内容不一样！

如果您在分支方面遇到麻烦，那是因为您滥用了SCM。我们已经做了很多年了。您拥有一个使用SCM来确定最终构建内容的系统。

这不是SCM的工作。SCM是美化的文件服务器。确定来自SCM的哪些文件进入构建的工作属于构建工具。

模块A正在开发中，并将进入您的每周发布。模块B是模块A，但其中包含项目X，并且正在同一分支中进行操作，但未在您的发行版中构建。在将来的某个时候，您要发布项目X。因此，您告诉构建工具停止放入模块A，然后开始放入模块B。

对此会有很多的哭泣和绞痛。什么风风雨雨，和一般的ling叫。这就是围绕诸如文件存储库之类的东西的情绪水平，无论多么聪明。

但是你有答案。

分支的主要问题是开发完成后很难合并回主分支。合并可能是一个手工操作并且容易出错，因此大多数时候应该避免合并。

我更喜欢分支的一些显着例外是大规模重构，比一个Sprint花费更长的时间开发巨型功能，或在大多数Sprint中中断其他功能开发的破坏性功能。

我推荐这种分支方案：

发布-测试-开发

然后从开发开始，按开发人员和/或功能进行分支。

每个开发人员都有一个分支，可以按常规进行操作，从中合并然后进入开发分支-理想情况下每天（只要它可以编译）。

这种方案非常适合在同一代码库上的许多开发人员和多个项目。

我们确实使用分支，但不使用功能的精细级别。我们为每个冲刺使用分支。从本质上讲，分支并不是IMO的坏事，因为它在功能或sprint层中模拟SOC的概念。您可以轻松地识别和管理哪个分支属于哪个功能或冲刺。

恕我直言，然后答案是，是。我们仍然应该使用分支。

我组织中的流程广泛使用分支机构和（看起来像这样的流程）持续集成。

从高层次来看，开发人员不必太担心与主线合并，他们只是致力于分支。（半）自动化过程检查计划将哪些功能纳入主线，合并这些分支并构建产品。该过程之所以有效，是因为我们实际上是从问题跟踪器集成了此合并过程，因此构建工具知道要合并的分支。