在不少技术群看到，有朋友问：“我们组现在的 Git 分支命名太混乱了，有没有一套大厂在用的标准？”我只能说，真该看看规范了。
就拿我们组早期的 Git 分支结构来说吧，堪称野蛮生长——new_ui_test_01、bug_fix_final_final_3、zhangsan_temp，这些命名，连 git log 自己都快看吐了，merge 的时候一个不注意就容易踩雷，分分钟把测试环境打成一锅粥。
后来，我们组统一规范以后，整个人都舒服了。你不说规范没用，一用了才知道，这玩意儿就是团队协作的润滑剂。
master 分支
先说最关键的 master 分支，很多新手喜欢直接在 master 上开发，出问题的概率简直不要太高。
master 分支在大厂里，基本只拿来干两件事：第一，作为生产环境的代码来源；第二，只允许 release 或 hotfix 分支合并进来。日常开发？一律滚远点！
这么搞的好处是显而易见的：稳定，出事了可以追溯，代码干净，测试覆盖全面，不会一不小心把“实验代码”扔上线。
所以，如果你下次还想在 master 分支上直接写代码，我建议你先请团队喝杯奶茶赔个不是。
develop 分支
说得好听点，develop 是一个集大家才华于一体的“开发环境分支”；说得现实点，它就是所有 feature、bugfix、style 等代码的“过渡旅馆”。
所有人在 develop 上合并、联调、找 bug，直到稳定之后，才会往下一个环节推进。别看 develop 乱哄哄的，它其实是个真正的“实战沙场”，代码冲突、模块互踢、接口不兼容，全在这里扯皮。越早发现问题，越不容易拖死上线时间。
我们组还有个小技巧：开发周期超过一天的功能，必须新建 feature 分支；一两小时内能搞定的小改动，可以直接在 develop 上改。这样一来，避免了分支太多的管理难题，又确保大功能有独立空间，不至于打架。
feature 分支
这一点太多人踩坑了。之前有个实习生在项目里建了个分支叫 testA_新版修复，你根本猜不到这是哪个模块的哪个功能。你问他怎么起名的？“我觉得这样我能记住啊……”
规范点的做法是，feature 分支一定要用 feature/功能模块名 来命名，比如：feature/login_page 或 feature/user_center，一看就明白是啥业务、由谁维护。
我们还额外加了项目缩写，比如
feature/bms-order-api（后台订单接口），这样一眼看上去就很清晰。
而且，feature 分支完工后必须合并回 develop，再删掉！不然到最后几十个没用的分支堆在仓库里，连 git branch 都要加载半天。
test 分支
我们都知道测试环境和开发环境是两码事，开发环境是“随便搞搞”，测试环境得是“稳定的可用版本”。
所以我们组会把 develop 分支上的代码，在联调完成后合并进 test 分支，给测试团队打包环境，方便他们验证。这个 test 分支其实就是 FAT 环境，对应的是 Feature Acceptance Test。
你要记住一件事：测试不等于开发完成，而是开发阶段的“第一次验收”。test 分支上要是出问题，别怪测试小姐姐骂你——她们经常背着锅上线了你没测全的 bug，最后锅还甩回开发。
release 分支
到了 release 分支，说明你要 UAT（用户验收测试）了，也就是正式上线前的“预演”。这时候的代码理论上不会再有大变动，只做些小修小补。
我们组的流程是：test 合并到 release，UAT 通过后，再由 release 合并到 master 和 develop，确保所有分支的代码都同步。别小看这一步，如果你只合进 master 不合 develop，下次又从 develop 拉新功能分支出来，bug 又被带回来了。
还有，release 分支上不建议直接开发，如果真的出现临时需求，还是在 hotfix 或 feature 分支上动手，搞完再合进来，别给上线流程添堵。
hotfix
热修分支，顾名思义，就是“线上的锅你得第一时间修”。它是从 master 上拉出来的，修完后要合回 master 和 develop，一边保证线上不炸锅，一边也把修复带进后续开发。
你可别把 hotfix 当成 feature 分支乱用了，那就失去了热修的意义。
而且命名必须规范，比如：hotfix/crash_homepage_bug，光看分支名就能猜到是首页崩溃修复，领导看到都说你“清楚”。
Git commit message
我们组之前的 commit message 是这样的：
你说这要是三个月后让别人看，他能理解你当初改了什么？我看都想直接 git revert。
现在我们统一用 Angular 的提交规范，最基本的格式就是：
<type>():
比如：
feat(login): 添加登录页面自动验证逻辑
fix(user): 修复用户信息接口数据错乱问题
这样写的好处太多了：
建议 commit 尽量粒度清晰，做到一次只改一类问题，不要多个功能混在一起提交，review 的时候你自己都说不清改了啥。
说说 .gitignore 那些“该进垃圾桶的文件”
每个 Java 项目都应该好好写一份 .gitignore，不然 target/、.idea/、*.log 这些奇怪的文件就通通混进代码仓库了。
我见过一次最离谱的提交，一个小哥把整个 build 目录 commit 上去了，直接导致项目从 200KB 变成 40MB，而且 CI 也跑不动。领导直接让他下次开会发言。
所以该忽略的就要忽略，不清楚的就去 GitHub 找类似项目的 .gitignore 模板抄一个，反正别瞎提。
规范不是枷锁
很多人一提规范就烦，总觉得是“上头管太多”。但其实真要哪天出事，比如：
- 半年前上线的一个功能突然报错，你翻 commit 看不懂；
- 新人看分支看得头晕，merge 错了删了别人的代码；
- 同一段 bug 修复了三次，因为没同步到 develop 分支；
你就会明白，规范不是为了限制你，是为了在关键时刻救你一命。
我们团队用了这些规范之后，整个开发流程都顺多了，版本发布也更可控了。你可以不高级，但不能不专业。Git 不就是一把菜刀么？怎么用，全看你怎么磨。
