Git Workflow for Teams: Branching Strategies That Work — cod-ai.com

三年前，我在我们这个50人的初创企业看到一位高级开发人员花了四个小时来解决一个蔓延到23个文件的合并冲突。罪魁祸首？一种在我们只有五个人时看起来合理的分支策略，但在我们扩展之后变成了一种负担。那一天让我们损失了一整次冲刺的生产力，这也让我意识到需要彻底重新思考我们如何处理Git工作流程。

我叫陈莎莎，过去12年我一直担任DevOps架构师，和团队合作从五人的初创企业到拥有200多名开发人员的企业组织。我见过各种Git工作流程——一些很棒，大多数普通，还有少数确实是灾难性的。我所学到的是没有一种放之四海而皆准的解决方案，但有一些原则可以将自信交付的团队与那些对下一个部署充满恐惧的团队区分开来。

统计数据令人 sobering：根据 GitLab 2023 年的调查，68% 的开发团队报告说，合并冲突和分支问题每季度至少导致一次主要的部署延迟。更令人担忧的是，34% 的开发人员每周花费超过五个小时处理与 Git 相关的问题，而这些问题与实际编码没有任何关系。这大约每年损失 260 个小时——超过六个完整的工作周——因工作流程摩擦而造成的。

糟糕分支策略的隐藏成本

在我们深入探讨解决方案之前，先谈谈真正的问题是什么。当我咨询遇到Git工作流程问题的团队时，他们通常集中于明显的痛点：合并冲突、部署延迟，以及偶尔需要强制推送的灾难性错误。但真正的成本要深得多。

考虑认知负担。每当开发人员需要创建一个分支时，他们都在做出决策：我该怎么命名这个？我应该从哪里分支？我应该什么时候合并回去？我应该多久变基一次？这些微决策会积累。我在三家中型公司进行的一项研究中，开发人员平均每天做出47个与Git相关的决策。当你的分支策略不清晰或过于复杂时，每一个决策都带来了不确定性和潜在的错误可能性。

然后是协作税。我曾与一家金融科技公司合作，他们的分支策略复杂得令人沮丧，以至于新开发人员需要三整天的培训才能理解工作流程。代码审查的延迟是由于审查者无法轻松理解更改的上下文。特性分支持续了几周，累积了冲突和与主代码库的偏差。当特性准备好合并时，因为基础已发生变化，需要进行大量重新测试。

财务影响真实存在。当我帮助一家拥有30名开发人员的SaaS公司优化他们的Git工作流程时，我们在六个月内跟踪了节省的时间。他们将解决合并冲突的时间减少了73%，将平均拉取请求周期从4.2天减少到1.8天，减少了41%的与部署相关的事件。从经济角度来看——假设开发人员的平均年成本为120,000美元——他们仅通过减少摩擦每年节省了大约180,000美元。这甚至不包括加快特性上市时间或改善开发人员士气的因素。

理解核心分支模型

让我们通过研究团队在生产中实际使用的主要分支策略来建立一个基础。我不打算给你教科书式的定义——我将告诉你这些在实践中的样子，附上一些来自真实团队的实际数据。

最佳的分支策略不是规则最复杂的那个——而是你团队在压力下实际遵循的一致的策略。

Git Flow 是结构化分支策略的始祖，由 Vincent Driessen 于2010年提出。它使用两个永久分支（main 和 develop），加上用于功能、发布和热修复的支持性分支。我在七个不同的团队中实施了 Git Flow，这里是我学到的：对于推出定期发布软件的团队，它工作得非常好，但对大多数Web应用来说则过于复杂。与我合作的一家电子商务公司在任何时候平均有14个活跃分支在Git Flow下。它们的发布过程涉及将develop合并到release中，进行测试，将release合并到main中，标记之后再将main合并回develop。这个过程每次发布需要6-8小时，并需要三个人正确执行。

GitHub Flow作为一个更简单的替代方案出现：一个主分支，其他一切都用特性分支，以及拉取请求作为进入生产的门户。它在简单性上体现了优雅。我建议的一家移动应用初创公司采用了GitHub Flow，并减少了60%的分支开销。他们从维护五种类型的分支减少到仅两种。他们的部署频率从每周两次增加到每天多次。但GitHub Flow有一个弱点：它假设你可以随时部署到生产。如果你需要暂存环境或发布协调，你将需要额外增加流程。

GitLab Flow处于中间位置，将环境分支（暂存、生产）添加到GitHub Flow的简单性中。我发现这对10-40名开发人员的团队非常有效，他们需要环境分离但又不想要Git Flow的复杂性。我曾与一家医疗软件公司合作，使用GitLab Flow维护开发、暂存和生产环境的独立分支。他们可以在暂存中测试特性，同时保持生产的稳定性，部署过程也很简单：合并到暂存、测试，然后合并到生产。

基于主干的开发是像谷歌和脸书这样高性能团队所青睐的方法。每个人都频繁地合并到main（主干）中——至少是每天一次。特性标志控制用户可见的内容。当我帮助一个25人的团队过渡到基于主干的开发时，他们持怀疑态度。“我们怎么可能把未完成的特性提交到main？”他们问。六个月后，他们的部署频率从每周增加到了每天多次，事件恢复的平均时间从4小时减少到45分钟。关键在于投资特性标志和全面的自动化测试。

为您的团队规模和成熟度选择正确的策略

这是大多数文章让你失望的地方：它们将这些策略呈现得好像它们对任何团队都是同样有效的选择。其实并非如此。您的团队规模、发布节奏和技术成熟度会显著影响哪种方法将会成功。