在开发一个电商项目时，小李和小王同时改了购物车功能，结果上线时代码对不上，查了半天才发现两人都建了叫“shopping”的分支，最后白白浪费半天时间。这种情况其实在小团队里太常见了，根源之一就是分支命名太随意。
为什么需要分支命名规范？
想象一下你走进一家超市，货架上全是写着“东西”的纸条，你要找洗发水得翻遍每个架子。Git仓库也一样，没人记得“fix-login”是上周修登录框的，还是三天前处理密码加密的。统一的命名规则就像商品分类标签，让每个人都能快速定位到自己要的内容。
推荐一套接地气的命名策略
直接上干货，我们团队现在用这套规则，新人两天就能上手：
<类型>/<简短描述>-<编号>
# 示例：
feature/user-profile-123
bugfix/login-error-456
hotfix/payment-crash-789
release/v1.2.0类型部分固定用这几个：feature（新功能）、bugfix（缺陷修复）、hotfix（紧急上线）、release（发布版本）。后面跟具体说明，用连字符连接，最后加上任务编号。比如 Jira 里的 TASK-123，直接写成 -123 就行。
实际工作场景中的好处
上周运营临时要求加个抽奖活动，我们立刻建了 feature/lottery-event-998 分支。一周后要查某个按钮样式是谁改的，直接 git log feature/ 一过滤，相关提交全出来了。要是还叫“new-page”或者“update-stuff”，现在就得翻历史记录猜谜了。
另外建议在项目根目录放个 CONTRIBUTING.md 文件，里面就写清楚这条规则。新同事第一次提 PR，自动检查工具发现分支名不对，直接打回去重命名，省得后期扯皮。
别搞得太复杂
见过有些公司规定分支名必须包含日期、开发者姓名、审批编号，结果每次都要查文档才能起名字。这就像给每瓶水贴上化学成分表，普通人只想知道是矿泉水还是可乐。简单清晰才容易坚持，别让规范变成负担。