git分支命名规范核心是统一前缀（feature/、bugfix/、hotfix/）、语义化命名（如feature/order-refund-v2）、禁用人名/时间戳，并配合严格分支生命周期管理与自动化校验，以降低协作成本、提升ci/cd效率。
没有“最高效”的分支策略，只有适配团队节奏和发布模式的策略——选错策略比不管理分支更伤效率。
feature/* 分支命名不规范导致 PR 评审混乱
团队里看到 feature/login、feat-login-2024、zhangsan-login 这类分支名，说明命名没收敛。这不是风格问题，是协作成本问题：评审人无法快速判断该分支是否已合入、是否还在开发、归属哪个迭代。
- 统一前缀：
feature/（新功能）、bugfix/（非紧急线上问题）、hotfix/（必须立刻上线的生产故障） - 名称中包含业务语义，比如
feature/order-refund-v2，而不是feature/refund - 避免带人名或时间戳，如
feature/zhangsan-pay或feature/pay-202607—— 人会换岗，时间会过期，但功能不会 - CI/CD 脚本可基于前缀自动分流：所有
hotfix/*推送后触发紧急构建，feature/*则只跑单元测试+静态扫描
develop 分支长期存在却无人维护
当 develop 分支的最后一次提交是 17 天前，而 main 已发布 v2.3.0，说明这个分支已沦为“幽灵分支”：它既不是集成入口，也不再代表下一个发布候选版本，只是历史遗留的符号。
- 如果团队采用主干开发（Trunk-Based Development），就根本不需要
develop分支——所有功能从main拉出短生命周期分支，合并回main前必须通过自动化门禁 - 如果坚持用
develop，它必须有明确的“准入门槛”：只有通过全部 E2E 测试 + 人工冒烟验证的 PR 才能合入，且每天至少一次git merge main同步线上热修复 - 定期清理：对超过 14 天无更新、无关联 PR 的
feature/*分支，自动发提醒；超 30 天未合入的，标记为stale并限制推送
hotfix 分支没从 main 拉取直接修在 develop 上
错误操作：git checkout develop && git checkout -b hotfix/fix-500 → 修复 → 合入 main。结果是：修复代码只存在于 main，但 develop 仍含旧逻辑，下次发版又把 bug 带回去。
-
hotfix/*必须严格从main拉取：git checkout -b hotfix/login-500 main - 修复完成后，先合入
main（立即发布），再反向合入develop（避免遗漏）：git checkout develop && git merge hotfix/login-500 - CI 应校验
hotfix/*的父提交是否为main最新 commit，否则拒绝推送 - 注意：若
main和develop差异过大，反向合并可能引入冲突——这时不是策略问题，是develop已失控，该砍掉重来
merge --no-ff 用错场景拖慢代码追溯
在 CI 自动化合入 PR 时仍强制使用 git merge --no-ff，会让 commit 图谱变成蜘蛛网：每个 PR 生成一个 merge commit，而真正有意义的变更被埋在子树深处。
- 仅在需要保留“功能边界”时用
--no-ff：比如release/2.4.0合入main，需明确标出本次发布包含哪些功能集 - 日常
feature/*合入main或develop，优先用git merge --ff-only或 rebase 后 fast-forward - GitHub/GitLab 的 “Squash and merge” 实际上等价于手动 rebase + ff，更适合保持线性历史——前提是开发者本地已 rebase 过，否则 squash 后丢失中间调试 commit
- 别为了“看起来有分支感”而牺牲
git bisect效率：一个带 20 个 merge commit 的失败构建，定位 root cause 的成本远高于一个干净的线性提交流
真正卡住效率的，往往不是分支模型本身，而是分支背后缺失的约束机制：没人检查命名、没人清理陈旧分支、没人校验 hotfix 起点、没人定义 merge 方式。策略只是骨架，落地细节才是血肉。
