你刚 pull 了 main 分支，终端弹出一串如同灾难预告的文字：
126 files changed, 47 conflicts
紧接着，群里就有同事在打字询问：“你为啥要 rebase？”
你的胃瞬间一紧，因为你已经预见到接下来会发生什么：有人会提议“先冻结一下分支”，有人会建议“我们得统一分支命名规则”，还有人可能会新建一个文档，名字大概率叫 workflow-v2。而你只会更加确信一件事：这些措施都不会让合并冲突的痛苦减少分毫。
如果这段话让你感同身受，那么问题可能不在于你的 Git 技能。你或许正身处一种“Git 宗教”之中。
许多 Git 工作流的设计初衷，并非是为了“顺利发布软件”，而是为了让团队“感觉安全”——通过增加流程、关卡和分支，制造出一种“复杂等于可控”的错觉。
直到现实无情地打破这种平静：一个紧急的热修复需求、两条相互冲突的功能分支、一个偏离主线的发布分支……这些精心设计的仪式便会瞬间崩塌。
真相其实很简单：一个有效的 Git 工作流只有一个核心任务：确保 main 分支始终保持可发布状态，同时不拖慢开发进度。 除此之外，皆为装饰。
仪式在所有人面前失败的那一天
我们也曾拥有一套“在白板上看起来非常专业”的流程：功能分支、集成分支、发布分支，并配有一条铁律：不到发布日，谁都别碰 main。
表面上纪律严明，也确实维持了一段时间的“平静”——直到它彻底失效的那一天。
一位同事将一个大型功能分支合并到了集成分支。紧接着，另一位同事也将另一个大型分支合入了同一个集成分支。单看每一个操作都合情合理，但放在一起却引发了冲突风暴。最致命的问题是：没有人需要对这场风暴负责。
构建状态持续报错，一直处于失败（红色）状态。但开发工作仍在继续，因为这套流程本身就在暗示：集成分支“脏”一点没关系。
然后，生产环境出了问题，必须立即修复。这不是一个可以留到下次迭代的优化，而是需要立刻上线的热修复。
当我们尝试将修复代码拣选（cherry-pick）到发布分支时：冲突。试图将发布分支合并回去时：冲突。尝试变基（rebase）时：冲突不仅存在，还换了地方出现。
压力之下，复杂的仪式流程最擅长做的事暴露无遗：制造更多的步骤、更多的不确定性，以及更多隐藏 Bug 的角落。
那一刻，我不再追问“官方推荐的流程是什么”，而是开始思考一个更根本的问题：什么样的工作流，能让失败变得平淡无奇？
唯一能在真实团队里存活下来的工作流
答案并非更“聪明”的分支策略，而是：更少的分支、存活时间更短的分支，以及对 main 分支近乎偏执的整洁度要求。
在我所见过的、能够跨团队规模化应用，又不会把 Git 管理变成第二份工作的实践中，只有一种模式做到了：Trunk-based development（主干开发） ——前提是必须严格执行其纪律，而非停留在口号层面。
它的简单程度甚至令人不安：
main: o---o---o---o---o---o-----> (永远可发布)
\ \ \
feat/a: o o o
feat/b: o---o
release: (tag) (tag)
这里没有长期存在、最终变成“平行宇宙”的 release 分支，没有在角落里悄悄“腐烂”的 integration 分支，也没有像在赌场下注一样的“合并日”。
整个流程只包含三样东西：main 分支、短命的功能分支，以及用于发布的标签（tag）。
听到这里，大多数团队都会提出那个共同的恐惧：
“那所有代码都合并进 main 了，岂不是连未完成的功能也会被发布上线？”
并不会。这正是下一块关键拼图登场的地方——Feature Flags（功能开关）。
让发布重归“冷静”的安全带：功能开关
功能开关的核心用途，远不止于进行 A/B 测试或实验。它最硬核的用途是：实现“合并但不发布”。
你可以将大功能拆解为多个小提交，持续合并到 main 分支，但这些新功能的代码默认处于“关闭”状态。等到一切准备就绪，再通过开关将其“打开”。这一个简单的机制，直接消除了团队滋生“分支丛林”的最大诱因。
实现模式非常简单：
const on = flags.on("new-payments");
if (on) {
payNew(req);
} else {
payOld(req);
}
它会潜移默化地改变团队的开发行为：
- 开发者不再倾向于将改动打包成“大而全”的提交，因为不再需要依赖“大型分支”来自我保护。
- 不再将工作长期隐藏在独立分支中“养到成熟”。
- 不再将代码冲突视为可怕的“天气预报”，因为冲突迟早会出现，早处理反而更简单。
- 开始愿意尽早进行合并，因为实践表明，早合并远比晚合并更安全。
开始量化效果后，争论便结束了
我不再与人争论“哪个流程看起来更优雅”，转而关注结果——那些直接影响软件交付效率和质量的硬性指标。
| 指标 |
采用复杂流程时 |
采用主干开发+功能开关后 |
| PR 平均规模 |
600 行 |
160 行 |
| 代码审查耗时 |
1.5 天 |
3 小时 |
| 每周合并冲突次数 |
12 次 |
3 次 |
最令人愉悦的并非仅仅是速度的提升，而是整个团队情绪和状态的改变。
PR 体积变小，审查者才能真正看得进去，思路不会中途“炸掉”。每日持续合并，冲突的规模和复杂度自然被控制。main 分支始终保持绿色（健康状态），开发者每次拉取代码时都充满信心，而非恐惧。
一个好的 Git 工作流最终交付的产品不是“代码历史的整洁”，而是团队持续交付的信心。
那条最容易让资深工程师感到不适的规则
要让这套流程真正生效，你必须坚决删除所有可以“躲避现实”的角落。这会让某些习惯于复杂流程的人感到不适。
我们制定了一条听起来有些刺耳的原则：存活时间过长的分支不是敬业的体现，而是在豢养潜在的 Bug。
因此，规则转变为：
- 所有分支默认必须是“短命”的。
- 大型功能必须被拆分为小片段，合并进 main 分支，但置于功能开关的保护之后。
- 绝不允许任何一个分支演变成开发者的“私人宇宙”，最后一次性以难以消化的大体积合并回来。
与此同时，我们将 main 分支视为“生产环境的表面镜像”：一旦 main 分支的构建或测试失败，修复它就是最高优先级的任务。这并非因为领导在监督，而是因为团队中每个人的后续开发与合并都依赖于一个健康的 main 分支。
当你持续实践一段时间后，会发生一件奇妙的事：团队不再需要频繁讨论 Git 工作流。它变得像空气一样——无处不在，却又不可见。
为什么“复杂仪式派”总能盛行？因为它提供了“责任缓冲区”
那些复杂的流程之所以生命力顽强，往往是因为它们为团队提供了一个“责任缓冲区”或“甩锅桶”：
发布分支可以“脏”，集成分支可以“不稳定”，合并日的痛苦被默认为“正常现象”。“流程就是这样规定的嘛。”
但这种痛苦并非天降，而是选择的结果。
简单的流程会迫使你直面真相：如果每次发布都痛苦不堪，要么是流程本身有问题，要么是单次改动过大，或者两者兼有。
当你的工作流强制你进行小改动、快速审查、并保持 main 分支始终绿色时，它也在强制你养成更好的工程习惯——不是靠空洞的口号，而是依靠近乎物理规律的工作约束。
你不再需要“表演 Git 操作的艺术”，而是可以真正专注于 交付可靠的软件。
发表于 5 天前
|
查看: 18|
回复: 0
