功能分支是邪恶的:从SVN迁移到Git经验


这是敏捷教练THIERRY DE PAUW分享他建议基于Git主干分支开发的思路和经验教训:
2012 年,我开始了一项技术指导任务,以提升一个新手团队的软件工程技能。从工程的角度来看是新手,而不是从工作经验的角度来看。他们的工作经验从 5 年到 20 年不等。
一开始,我们遇到了一个我们没想到在 2012 年仍然会发现的情况。团队中除了一个人之外,没有人在使用任何版本控制系统。代码在团队成员之间使用……共享驱动器共享。部署也发生在……共享驱动器上。
 
首先使用SubVersion
显然,作为第一个动作,我们引入了版本控制。由于团队是使用版本控制系统的新手,我认为 Git 会成为一座桥梁。需要学习的概念太多。因此我建议使用SubVersion。它很容易使用。你只需要掌握三个概念:

  • 你看看代码,
  • 你修改它,
  • 然后您将其重新签入。
  • 你已经完成了。相当简单,不是吗?

因为从各方面来看,SubVersion 分支是相当痛苦的——比 CVS 麻烦,但比 Git 要求更高——我还建议根本不使用分支。团队中的每个人都将直接投入主干。坦率地说,当时我对分支策略了解不多。这一切对我来说似乎太复杂了。我很难在脑海中适应工作流程。
那效果很好。因为……我们从一开始就引入了第二件事,即持续集成的实践和 团队承诺,即任何更改都必须由自动化测试覆盖,最好是单元测试。
持续集成后来演变为持续交付。
当时,我没有意识到这是一个有效的分支策略。而且它实际上有一个名字。几年后我才发现它被命名为 Trunk-Based Development。
 
使用Git
当团队成熟时,我们认为是时候迁移到 Git 了。做出这一决定的原因有两个:
  • 有更多工具可用于管理 Git 存储库;
  • 我们希望采用 Pull-Request 模型进行代码审查,因此分支创建必须毫不费力,没有摩擦。

但是……对于核心团队维护系统并接受外部贡献的开源社区有用的方法,对于企业环境中的同地团队来说不一定非常有效。
与团队一起,我们猛烈地解决了功能分支带来的问题。分布式版本控制系统 (DVCS) 的支持者依靠功能特征分支来销售 DVCS 以及围绕 DVCS 存在的所有工具这一事实使每个人都对使用特征分支所产生的问题视而不见。
我们试图通过引入越来越复杂的过程和越来越复杂的技术来寻找解决方案。但它从来没有真正解决潜在的问题,除了增加了大量的复杂性。最后,我们坐在一起讨论这件事,决定放弃使用功能分支。我们回到了对我们有用的东西,即基于主干的开发。我们从未回头。
 
八年后
8 年后的 2021 年 1 月,我受团队组织的邀请, 作为培训的一部分展示了Feature Branching is Evil。在问答过程中,我发现团队还在实践基于主干的开发。他们仍然无法想象一种不同的工作方式。对他们来说,这是最自然的事情。
 
经过这次经历,在 2016 年的某个时候,我在一个完全不同的组织中开始了新的使命。非常敏捷,与技术娴熟的工程师一起工作,大多数时候每个人都是结对工作。但是……他们决定作为一个组织使用GitFlow。到达时,我发现分支机构的寿命从 5 天到 30 天不等。人们不得不频繁地将主线重新设置到他们的分支中,这导致了大量的返工,并花费了大量无价值的时间来修复损坏的东西。
凭借我在该新手团队中获得的经验,我建议进行基于主干开发的实验。
自 2015 年以来,DevOps 状态报告已经报告了基于主干的开发 来预测高软件交付性能;
Facebook、Microsoft、Netflix 和 Google 等组织大规模实施了基于主干的开发