git分支命名混乱导致不可读、合并冲突频发、hotfix绕过测试、stale分支堆积等问题，根源在于缺乏统一前缀（如feature/、hotfix/）、强制jira id或描述、自动化校验及生命周期管理。
分支命名混乱导致git branch输出不可读
当你执行git branch看到一堆类似feat/user-login-v2-fix、fix-bug-2025-07、temp-merge-test、dev-john-2024的分支名，说明命名已失控。这类名字既无法反映生命周期（是临时分支还是长期维护分支？），也无法体现归属或意图（谁建的？为什么建？是否已完成？）。
实际影响是：团队成员不敢删分支，怕误删未合入的改动；CI/CD脚本因匹配不到规范分支名而跳过构建；git log --oneline --all变成视觉噪音，关键提交被淹没。
- 统一前缀：只允许
feature/、hotfix/、release/、bugfix/四类前缀（避免dev-、tmp-等随意前缀） - 强制后缀：所有分支必须带 Jira ID 或简明描述，如
feature/LOGIN-123-sso-integration，禁止无意义数字或日期 - 自动化拦截：在 Git Hooks 或 CI 中用正则校验
git branch --format="%(refname:short)"输出，不合规分支拒绝推送
git merge冲突频发且难以追溯根源
碎片化分支往往意味着大量短命分支反复从develop拉出、又反复向develop合并，每次合并都引入微小差异，最终导致git merge时出现“看似无关文件却报冲突”的情况——比如package.json里同一行依赖版本被不同分支各自 bump，Git 无法自动判断哪个更合理。
这不是 Git 的问题，而是分支粒度太细、集成节奏太松散造成的逻辑耦合。
- 禁止单人长期持有独立开发分支：超过 3 天未向
develop同步的feature/分支，自动触发 Slack 提醒 - 要求每日至少一次
git pull origin develop并解决本地冲突，而非攒到合并前一次性处理 - 对
package-lock.json、pnpm-lock.yaml等锁文件启用merge=union策略（在.gitattributes中配置），避免琐碎冲突
hotfix 分支绕过测试流程直推 master
当团队习惯用hotfix/分支快速修复线上问题，却省略了从hotfix/→develop的反向同步，就会出现“线上已修、开发环境仍复现”的诡异现象。更危险的是，有人直接在hotfix/上改完就git push origin master，跳过 CI 流水线和 Code Review。
这本质是把 hotfix 当成了“特权通道”，破坏了质量门禁。
- 所有
hotfix/分支必须同时合并到master和develop（顺序为先master再develop） - CI 配置强制检查：若推送目标为
master，且来源分支不含hotfix/前缀，则拒绝 - 用
git cherry-pick -x替代手动复制代码，确保提交信息里带原始 hash，便于后续审计
长期存活的 stale 分支占用远程仓库空间且误导新人
git branch -r | grep -c "origin/"返回 287，但其中近 60% 分支最后一次推送超过 90 天，且对应 PR 已 close —— 这些就是 stale 分支。它们不会被自动清理，却持续出现在 IDE 的分支选择下拉框、Git Graph 插件的视图里，新人容易误切、误基于其开发。
GitHub/GitLab 虽提供“自动删除 merged branches”选项，但仅对 PR 合并后的分支生效；手动合并、git merge --ff-only或 rebase 后的分支不会被识别。
- 每周执行一次清理脚本：
git branch -r --merged origin/master | grep -v "origin/master\|origin/develop" | sed 's/origin\///' | xargs -I {} git push origin --delete {} - 在 README.md 显眼位置写明分支生命周期规则：“
feature/分支合并后 3 天内由创建者删除” - 给所有 stale 分支打 tag，如
stale/2025-Q3-feature-x，保留历史快照但移出主分支列表
hotfix/流程，或者某人悄悄保留了一个dev-xxx分支半年，碎片化就会立刻回潮。
