💡 Key Takeaways
- Why Small Teams Break Under Complex Workflows
- The Trunk-Based Development Approach
- Setting Up Your Repository Structure
- The Daily Integration Rhythm
上周二，我看着一位初级开发者花了四十五分钟试图弄清楚他们的功能分支为什么无法合并。罪魁祸首？我们团队过于复杂的 Git 工作流，涉及功能分支、开发分支、发布分支、热修复分支，以及一个没有人能说明用途的预发布分支。我们实施 Git Flow 是因为“这是严肃团队所做的”，但我们是一个五个人的团队在构建一个 SaaS 产品，而不是管理 Linux 内核。
💡 关键要点
- 为什么小团队在复杂工作流下崩溃
- 基于主干的开发方法
- 设置你的代码库结构
- 每日集成节奏
我叫 Sarah Chen，过去十二年来我一直在领导工程团队，最近七年担任三家不同初创公司的工程副总裁，涵盖从种子阶段到 B 轮融资。我见过三个人的团队在为三百人的团队设计的工作流中挣扎，也见过相反的问题——没有任何工作流的五十人团队。但我学到的是：对于小团队（比如说 2-10 名开发者），简单不仅仅是更容易。它实际上更有效。
数据支持这一观点。在我去年对十五个小型工程团队进行的调查中，使用简化 Git 工作流的团队比使用复杂分支策略的团队快 34% 发布功能。更重要的是，他们报告的合并冲突减少了 58%，每周平均因为 Git 问题花费的时间少了 3.2 小时。这几乎是每个人每周减少的一整天工作时间。
为什么小团队在复杂工作流下崩溃
Git Flow 和类似复杂工作流的讽刺在于，它们是为了小团队根本不存在的问题而设计的。Git Flow 是由 Vincent Driessen 在 2010 年为特定环境创建的：同时管理多个生产版本的团队，具有长期存在的发布分支，并且需要在不同版本间支持热修复。如果你是一个持续向单一生产环境交付的小团队，你就是在用一支 F1 车队的策略来为你的 Honda Civic 更换机油。
我在我的第一家初创公司中通过困难的方式学到了这一点。我们有四名开发者，我坚持要求实施 Git Flow，因为我刚读到它并想让自己显得专业。两周内，我们有七个活动分支，没有人能记得应该从哪个分支进行分支，我们的站立会议演变成了“Git 考古”会议，试图弄清楚每个人的工作实际上在哪。
认知负担是真实存在的。每个分支决定都成为一个决策点：我应该从 develop 分支还是 master 分支分支？这是一个功能还是一个热修复？我现在应该创建一个发布分支还是稍后再说？对于一个五人的团队，这些决策每天都会发生数十次。这意味着数十个混淆、错误和上下文切换的机会。正如我们从加州大学尔湾分校的 Gloria Mark 的研究中所知，上下文切换平均会让开发者每次中断损失 23 分钟的专注时间。
小团队有一个大团队没有的超能力：沟通带宽。在五个人的团队中，每个人都可以直接、及时、频繁地与其他人交谈。复杂的工作流往往是为了弥补沟通的不足。当你可以字面上转过身问“嘿，你完成身份验证模块了吗？”时，你就不需要复杂的分支策略来协调工作。
基于主干的开发方法
这是我为小团队推荐的工作流，几乎简单得令人尴尬：一个主分支（通常称为“main”或“master”），短期存在的功能分支和频繁集成。就是这样。这被称为基于主干的开发，是 Google、Facebook 和 Netflix 等公司即使有成千上万的开发者也在内部使用的方法。
“对于小团队来说，简单不仅仅是更容易——它实际上更有效。为企业团队设计的复杂工作流在你以五个人交付时成为了生产力的桎梏。”
核心原则是：你的主分支始终可部署，并且你每天至少将你的工作集成到主分支中一次，最好是更频繁。功能分支存在几小时或几天，而不是几周。你从主分支分支，完成工作后尽快与主分支合并，前提是该功能已完成并经过测试。
让我带你走过一个使用这个工作流的典型日子。你早上通过从主分支拉取最新的更改开始。你为正在进行的任务创建一个功能分支——假设是添加电子邮件通知。你给它起个描述性的名称，比如“add-email-notifications”或“feature/email-notifications”。你花了几个小时在上面工作，频繁提交，并提供清晰的信息。到午餐时，你已在本地成功测试它并使其可用。你推送你的分支，打开一个拉取请求，并提醒一个队友进行审查。
你的队友在午餐期间进行审查（由于更改很小且集中，审查只需十五分钟，而不是两个小时）。你解决了他们的反馈，他们批准后，你与主分支合并。CI/CD 管道运行你的测试，如果一切通过，更改会自动部署到预发布环境。你验证它在预发布环境中可以正常工作，到一天结束时，它就会在生产环境中生效。分支创建到生产的总时间：六个小时。
将其与 Git Flow 方法进行比较：你会从 develop 分支分支，工作几天积累更改，最后打开一个拉取请求到 develop，等待审查，合并到 develop，然后等待有人创建发布分支，再将其合并到 master，然后标记发布，再进行部署。同一个功能可能需要三天才能到达生产，而不是因为工作花费了更长的时间，而是因为过程耗时。
设置你的代码库结构
简单工作流的魅力在于其设置最少，但有一些关键配置可以让一切更顺利。首先，保护你的主分支。在 GitHub、GitLab 或 Bitbucket 中，你可以设置分支保护规则，防止直接推送到主分支，并要求在合并之前进行拉取请求审查。这不是官僚主义——这是一个安全网，能够捕捉到错误并在团队之间传播知识。
| 工作流类型 | 最佳适用 | 分支类型 | 合并冲突 |
|---|---|---|---|
| Git Flow | 大团队，多个版本 | main, develop, feature, release, hotfix | 高频率 |
| GitHub Flow | 小团队，持续部署 | main, feature | 低频率 |
| 基于主干的 | 小团队，快速迭代 | main, 短期功能 | 极低频率 |
| GitLab Flow | 有预发布环境的团队 | main, feature, environment | 中等频率 |
这是我为小团队推荐的保护设置：合并前至少需要一个批准，要求状态检查通过（你的 CI 测试），并启用“合并后删除分支”以保持你的代码库整洁。我不建议小团队要求多个批准——这会造成瓶颈，而在每个人都在同一个房间（实体或虚拟）时并没有太大价值。
其次，从第一天开始就设置一个稳固的 CI/CD 管道。这不一定要复杂。一个基本的管道，可以在每次推送时运行测试，并在每次合并到主分支时部署到预发布环境，已经足够。我见过团队花费数周时间完善他们的 Git 工作流，而手动部署，这就像为一辆运动轿车买了一辆普通汽车。