Trunk 分支必须叫 main（或 master），因其是 TBD 的单一权威主线，CI/CD、权限策略等均硬编码依赖此名；改名将导致构建跳过、PR 检查失效。
为什么 trunk 分支必须叫 main（或 master），不能随便起名
Trunk-Based Development（TBD）的核心是“单一权威主线”，这个主线在 Git 中就是 main（或历史遗留的 master）。它不是命名偏好问题，而是协作契约：所有开发者默认向这里集成，CI/CD 流水线、部署系统、权限策略都硬编码依赖这个分支名。如果你改成 trunk 或 dev-main，git push origin trunk 看似能推上去，但 CI 会因找不到 main 而跳过构建，PR 合并检查也会失效。
实操建议：
- 初始化仓库时立刻重命名：
git branch -M main（Git 2.28+ 默认行为，旧版需手动） - 团队内禁止创建同义分支（如
production-ready），避免开发者误以为“可以先合到那里再转主干” - GitHub/GitLab 的默认分支设置必须同步为
main，否则新 PR 默认目标错位
feature 分支怎么建才不破坏 TBD 的“短生命周期”原则
TBD 要求 feature 分支存在时间 ≤ 1 天，本质是防止“隐性集成风险”。很多人建了 feat/user-login-rewrite 就放着写三天，最后发现和 main 差了 20 个提交，冲突一堆——这不是 TBD，这是带分支壳的野蛮开发。
实操建议：
- 分支名用编号 + 极简动词：
feat/123-login-refactor，不加形容词、不体现技术细节（比如不用feat/123-login-refactor-with-jwt） - 每天下班前强制执行一次
git pull --rebase origin/main，不是“等快好了再合并”，而是“让 rebase 成为肌肉记忆” - 如果某功能真需要多日开发，拆成原子任务：第一天实现接口存根（可测），第二天补校验逻辑，第三天接 UI —— 每个任务单独分支、单独 PR
CI 失败后，为什么不能先 merge 再 fix
这是 TBD 最常破防的瞬间：CI 报 test_auth_timeout 失败，有人直接 git push origin main 强推修复，或者更糟——在 PR 里点 “merge anyway”。后果是：下一个开发者 git pull 下来就带着一个已知失败的测试用例，他的本地构建也挂，但他不知道是自己代码问题还是继承来的坏状态。
实操建议：
- CI 失败 = 立即停止所有向
main的推送，包括 hotfix。修复必须走新 PR，哪怕只改一行 - 禁止配置
allow_merge_on_failed_checks: true（GitHub）或allow_failure: true（GitLab CI）这类宽松选项 - 把
npm test或pytest --fail-on-warning加进 pre-commit hook，让问题卡在本地，别等 CI 揭穿
如何识别你其实没在用 TBD，只是在用“名字叫 main 的长周期分支”
真正落地 TBD 的信号很朴素：每周 main 上有 50+ 次合并（含 squash merge），且 90% 的 feature 分支存活时间 ≤ 4 小时；反观“伪 TBD”常见症状是：PR 描述里写“请尽快 review，我下周上线”，分支创建日期比当前日期早 3 天，git log --oneline origin/main...HEAD 显示差异超过 15 个提交。
实操建议：
- 用
git for-each-ref --format='%(refname:short) %(committerdate:iso8601)' refs/heads/ | grep -v 'main\|develop'快速扫出陈旧分支 - 在团队看板上公开显示“分支平均存活时长”，数值 > 8 小时就要触发复盘
- 删除长期 feature 分支前，别只看
git branch -d是否成功——先git diff main...<branch>
确认没漏掉关键修改
复杂点在于：TBD 不是分支策略，是集成节奏的约束。名字对了、命令对了，但没人每天 rebase、没人敢删分支、CI 一挂就绕过——那 trunk 只是块墓碑。
