开发一个项目，最怕什么？不是写不出代码，而是几个人改同一块功能，结果合并时冲突一堆。上周我们团队就遇到这事儿，小李改登录逻辑，老王也在动这块，等提交的时候发现两人的代码完全对不上，最后花了半天才理清楚。
什么是主干分支策略
主干分支策略（Trunk-Based Development）说白了就是大家主要在一条主线（也就是主干，trunk）上开发，每次改动都尽量小而快，频繁提交，而不是拉出一堆长期存在的分支。它不像某些公司搞的“功能分支满天飞”，一个人一个分支，一个月都不合回来。
举个生活里的例子：你家厨房只有一个灶台，如果一家人做饭都想用，总不能一个人占着不走吧？得轮流来，做快点，做完让下一个上。主干分支也是这个道理——别霸着分支不放，快速提交，快速验证。
怎么落地
我们现在的做法是：所有人基于 main 分支开发，新功能通过短生命周期的分支进行，通常不超过一天。如果功能太大，就拆成小步骤，每步都能独立运行或关闭。
比如上线前要加个新按钮，我们不会整个功能做完再提交，而是先提交结构，再补样式，最后接逻辑。中间每一步都可以合并进主干，配合特性开关（Feature Flag），不让未完成的功能影响线上用户。
配置示例
branch: main\nmerge_strategy: fast-forward\nprotected: true\nallowed_pushers: \n - team-lead\nrequired_reviewers: 1\nallow_deletions: false像 GitHub 或 GitLab 都支持设置主干保护规则，禁止直接推送，必须走 PR/MR，还得有人审核。这样既能保证质量，又不会阻塞进度。
以前我们用的是“功能分支+长时间开发”的模式，结果每次发版都像拆弹，生怕哪个分支漏了更新，或者冲突解决错了。改成主干策略后，每天都在集成，问题早暴露，反而更稳了。
当然，这招也不是万能的。如果你的项目依赖复杂、测试周期长，那可能需要搭配 CI 流水线一起上。我们就在 Git 提交后自动跑单元测试和构建，失败了立刻通知，避免污染主干。
现在团队节奏明显顺了，没人再抱怨“他又改了我的代码”，因为每个人都在持续同步，改的都是最新版。