feature分支一用就乱的核心原因是缺乏明确的生命周期规则（如7天内必须合并或关闭）和强制的ci检查项（如pr前须通过单元测试与代码风格检查）。
直接说结论：转型不是换套流程文档就能跑起来的事，核心卡点在「开发习惯切换」和「合并节奏失控」——前者靠机制约束，后者靠自动化拦截。
为什么 feature 分支一用就乱？
常见现象是：feature/login、feature/payment-v2 长期不合并，develop 分支越来越难同步，CI 构建频繁失败，最后变成“谁都不敢动主干”。根本原因不是 Git 不行，而是缺少两个东西：
- 明确的分支生命周期规则（比如：创建后 7 天内必须合并或关闭）
- 强制的 CI 检查项（比如：PR 提交前必须通过单元测试 + 代码风格检查）
没有这两条，git checkout -b feature/xxx 就只是多开了个本地目录，不是工作流。
feature 分支怎么命名才不踩坑？
命名不是为了好看，是为了让 git log、CI 脚本、Git Hook 和人一眼看懂意图。别用 feature/new 或 feature/fix 这类模糊名：
- 必须带上下文：用
feature/user-auth-jwt，而不是feature/auth - 避免版本号混入：写
feature/billing-refactor，不写feature/v3-billing（版本由 tag 管，不分支管） - 禁止使用空格、下划线以外的符号：
feature/user_auth✅，feature/user-auth!❌（部分 CI 工具会截断或报错）
Git 本身不限制命名，但 Gitee/GitHub 的 Web UI、CI 脚本、权限策略都依赖稳定格式解析分支名。
合并前必须做的三件事
很多团队把 PR 当成“提交按钮”，其实它是协作临界点。合并前漏掉任意一项，都会导致 develop 分支质量滑坡：
-
git rebase -i origin/develop：把 feature 分支变基到最新develop，不是简单git merge develop——后者会引入无意义的 merge commit，干扰 bisect 和 blame - 本地运行完整测试集：
npm test或make test，不是只跑改动文件的单测 - 检查 CI 输出是否真绿：有些 CI 显示 “✅ passed”，但实际跳过了 lint 或覆盖率检查，要看原始日志里的
exit code 0
尤其注意：rebase 后必须 git push --force-with-lease origin feature/xxx，不能直接 push -f，否则会覆盖别人刚推的新提交。
dev 和 main 分支到底谁该当“集成中心”？
答案取决于你有没有自动化发布能力。如果上线还要手动打 tag、改配置、走审批流程，main 就是事实上的集成中心；如果已接入 CD 流水线，能自动从 develop 构建预发环境并触发 E2E 测试，那 develop 才是真正的集成中心。
关键判断依据：git log --oneline develop 的提交密度。如果平均每天不到 1 条，说明 develop 没被真正用起来——它只是个“缓冲区”，不是“集成器”。这时候要先解决 CI/CD 卡点，而不是纠结分支名要不要加 dev/ 前缀。
