Git 工作流实践：我们团队从 Git Flow 切换到 Trunk-Based 的经验
Git Workflow in Practice: Our Team's Switch from Git Flow to Trunk-Based Development
| Alex | 2026-08-26T10:02:35
用了两年 Git Flow 之后，我们决定切换到 Trunk-Based Development。切换过程中遇到的问题和解决方案记录在这里。
After two years with Git Flow, we switched to Trunk-Based Development. Here are the challenges we faced and how we solved them.
我们团队用了两年 Git Flow，一开始觉得挺规范的，但是后来越来越痛苦。今年年初下定决心切换到了 Trunk-Based Development，用了半年感觉很香。 为什么放弃 Git Flow Git Flow 的问题在我们这种小团队（8 人）体现得特别明显： 合并冲突地狱：feature 分支动不动开好几周，合并回 develop 的时候冲突一大堆 发布流程太重：切 release 分支、测试、合并回 main 和 develop、打 tag，一次发布要折腾半天 hotfix 的同步问题：hotfix 完了要同时合并到 main 和 develop，经常漏掉 CI/CD 配置复杂：要给 feature、develop、release、main 分别配 pipeline Trunk-Based 怎么做的 核心原则就是：所有人都往 main 分支提交，分支生命周期不超过一天。 短命分支 开一个 feature 分支，做完就提 PR，当天合并。如果一个功能太大，就用 Feature Flag 拆分，先合并进 main 但不对外可见。 Feature Flag 我们用了一个简单的配置中心来管理 Feature Flag： if (featureFlags.isEnabled("new-checkout-flow", userId)) { return newCheckoutFlow(order); } else { return legacyCheckoutFlow(order); } 新功能先在内部灰度测试，确认没问题了再全量放开。 自动化测试是基础 Trunk-Based 能跑起来的前提是有靠谱的自动化测试。我们的 PR 合并条件： 单元测试全部通过 集成测试全部通过 至少一个人 Code Review 通过 Lint 检查通过 切换过程中的坑 最大的问题是团队习惯的转变。有人习惯了在 feature 分支上随便提交，切换到 Trunk-Based 之后每个 commit 都有可能影响 main，需要更谨慎。 还有就是 Feature Flag 的管理，如果不及时清理旧的 flag，代码里会到处都是 if-else，变得难以维护。我们定了一个规矩：功能上线稳定运行两周后，必须删除对应的 Feature Flag。 效果 切换半年后的数据对比： 发布频率：每两周一次 → 每天 2-3 次 PR 平均合并时间：3 天 → 4 小时 合并冲突次数：每周 5-6 次 → 每周 0-1 次 从提交到上线：5-10 天 → 当天
After two years with Git Flow, we switched to Trunk-Based Development. The pain points with Git Flow were clear for our 8-person team: merge conflict hell, heavy release process, hotfix sync issues, and complex CI/CD configs. How We Do Trunk-Based Core principle: everyone commits to main, branch lifetime under one day. Large features use Feature Flags for incremental rollout. Results After 6 Months Release frequency: biweekly → 2-3 times daily Average PR merge time: 3 days → 4 hours Merge conflicts: 5-6 per week → 0-1 per week