tbd中feature/xxx分支生命周期硬约束为24小时，超时即退化为隐式gitflow；须通过ci校验、分支保护规则、pre-commit钩子及feature flag强制拆解与兜底。
特性分支生命周期超过24小时，TBD就已失效——这不是建议，是实测阈值。 超过一天的 feature/xxx 分支，在CI流水线、测试覆盖和协作节奏没跟上的前提下，实际行为已退化为隐式GitFlow，只是分支名短而已。
为什么24小时是硬约束而非经验值
这个时间不是拍脑袋定的，而是由三类现实瓶颈共同挤压出的窗口：
- 主干每小时可能有3–5次合入，
git merge main后未跑测试就 push，极易把别人刚引入的 bug 一起带进分支 - 本地
jest --ci或mvn test平均耗时8–12分钟；若分支停滞超半天，再同步时大概率触发“冲突+测试失败+环境漂移”三连击 - Feature Flag 的兜底能力只对“已合入但未启用”的逻辑有效；分支长期游离，Flag 就成了摆设，等于裸奔
如何强制把 feature 分支压到 1 天内
靠提醒没用，得靠流程卡点和工具拦截：
- GitHub/GitLab 的 branch protection rules 中启用
Require status checks to pass before merging，并绑定ci/test和ci/lint两个必需检查项 - 在 CI 脚本开头加校验：
if [ $(git log --since="24 hours ago" origin/main..HEAD | wc -l) -eq 0 ]; then echo "Branch older than 24h, aborting"; exit 1; fi - 开发人员本地 pre-commit hook 中集成
git merge-base --is-ancestor origin/main HEAD || (echo "Not based on latest main"; exit 1)，防止忘 pull 就开干
拆不掉的大功能怎么办
所谓“拆不掉”，往往是因为没提前设计 Feature Flag 的切口位置。真实项目里，能落地的方案只有两种：
- 前端：在路由层或组件
useEffect入口统一读取unleash.isEnabled('payment-v3')，未启用时 fallback 到旧支付页，且禁止加载任何 v3 相关 chunk - 后端：HTTP handler 入口用
if !flags.IsEnabled(ctx, "payment-v3") { return legacyHandler(w, r) }，所有新逻辑包裹在 flag 块内，数据库 migration 单独走灰度开关 - 绝对不要做的是：把 flag 放在 service 层深处，或者只控制 UI 显示而放行后端调用——这会让 QA 环境无法验证完整链路
真正难的不是写代码，是让每个 feature/xxx 分支从诞生起就带着倒计时；一旦超时，CI 流水线必须拒绝构建，而不是等它自己“努力赶工”。否则，main 分支的稳定性就全靠人肉盯盘来维系。
