分支开一周才合回来：目录站的分支策略和发布节奏该怎么定

分支策略的争论经常变成审美之争，其实它有一个可以量化的核心变量：分支从开出到合并之间的时间。

时间越长，主干上积累的变化越多，合并时要处理的冲突就越复杂，而且复杂度不是线性增长的。DORA 的多年研究把「短命分支」的界线画在一天以内，2024 年的报告里高效能团队绝大多数走的是主干开发、分支存活不超过一天。长期存在的特性分支则和更高的变更失败率相关。

图片来源：网络，版权归原作者所有，侵权请联系删除

三套做法各自的适用面

策略	永久分支	适合什么	不适合什么
主干开发	只有 main	自动化测试扎实、每天部署多次	测试薄弱，靠人工验收
GitHub Flow	只有 main	多数小团队的默认选择	要同时维护多个已发布版本
GitFlow	main + develop	有合同约束的发布、多版本并行维护	持续部署的 Web 站点

GitFlow 是 2010 年由 Vincent Driessen 提出的，当时的背景是盒装软件和需要门店审核的移动应用——发布是按日历走的。目录站是持续部署的 Web 站点，套这套流程只会带来两套主线的漂移和一堆合并仪式。

对三五个人的目录站团队，GitHub Flow 是合适的默认选项：一条 main 永远可部署，其余都是短命分支，走 PR 合并。等自动化测试铺开了，再往主干开发靠。

分支要短，前提是能拆

一天合并一次是目标，但一个功能常常要写好几天。矛盾的解法不是硬砍，而是四种拆分手段：

• 功能开关：代码先合进去，默认关闭，等完整了再打开
• 抽象分支：重构类改动先加一层接口，再换实现，最后删旧的，每一步都能独立合并
• 堆叠 PR：一个多天的改动拆成三个互相依赖的小 PR，底下的先合，上面的跟着变基
• 按执行路径拆：骨架、主流程、边界情况，各自一个 PR

没有功能开关这个前提，主干开发会退化成长命分支——工程师会把代码攥在手里直到「做完」，而「做完」永远比预期晚。

目录站的两个特殊节奏

第一是数据迁移必须和代码发布分开跑。改表结构的脚本先上，确认执行完成且应用兼容新旧两种结构，再发依赖新结构的代码，最后清理旧字段。三段之间可以隔几天，不能挤在一次发布里。这和批处理任务的顺序是同一个道理。

第二是热修路径要提前演练。线上出问题时没人有余裕翻文档，所以平时就要确认：从哪个提交拉热修分支、合并回 main 后要不要同步到开发分支、版本号怎么打、回滚是还原代码还是再发一个反向补丁。回滚优先还原代码，反向补丁容易漏掉某个字段。

发布节奏和 SEO 没有直接关系，但有间接影响

搜索引擎不关心你用什么分支模型。它关心的是发布前后 URL 有没有变、页面结构有没有跳变、以及会不会出现几分钟的 500。所以真正要守的是几条：URL 结构改动必须配重定向并提前验证；模板大改先灰度到一部分分类页；每次发布后跑一遍关键页面的状态码检查。

把分支存活时间当成一个要盯的指标，比争论用哪套流程有用得多。每周看一眼哪些分支超过三天还没合，找到原因，流程自然就顺了。