原文链接 Git 分支设计规范 在本文基础上有所修改
概述
这篇文章分享 Git 分支设计规范，目的是提供给研发人员做参考。
规范是死的，人是活的，希望自己定的规范，不要被打脸。
在说 Git 分支规范之前，先说下在系统开发过程中常用的环境。
| 简称 | 全称 |
|---|---|
| DEV | Development environment |
| FAT | Feature Acceptance Test environment |
| UAT | User Acceptance Test environment |
| PRO | Production environment |
- DEV 环境：用于开发者调试使用。
- FAT 环境：功能验收测试环境，用于测试环境下的软件测试者测试使用。
- UAT 环境：用户验收测试环境，用于生产环境下的软件测试者测试使用。
- PRO 环境：就是生产环境。
比如，项目域名为：http://www.abc.com，那么相关环境的域名可这样配置：
- DEV 环境：本地配置虚拟域名即可
- FAT 环境：
http://fat.abc.com - UAT 环境：
http://uat.abc.com - PRO 环境：
http://www.abc.com
接下来，针对不同的环境来设计分支。
分支
|分支 | 名称 | 环境| 可访问| | —- | —- | —- | —- | |master | 主分支 | PRO |是| |release| 预上线分支 | UAT |是| |hotfix | 紧急修复分支| DEV |否| |develop| 测试分支 | FAT |是| |feature| 需求开发分支| DEV |否|
master 分支
master 为主分支，用于部署到正式环境（PRO），一般由 release 或 hotfix 分支合并，任何情况下不允许直接在 master 分支上修改代码。
release 分支
release 为预上线分支，用于部署到预上线环境（UAT），始终保持与 master 分支一致，一般由 develop 或 hotfix 分支合并，不建议直接在 release 分支上直接修改代码。
如果在 release 分支测试出问题，需要回归验证 develop 分支看否存在此问题。
hotfix 分支
hotfix 为紧急修复分支，命名规则为 hotfix- 开头。
当线上出现紧急问题需要马上修复时，需要基于 release 或 master 分支创建 hotfix 分支，修复完成后，再合并到 release 或 develop 分支，一旦修复上线，便将其删除。
develop 分支
develop 为测试分支，用于部署到测试环境（FAT），始终保持最新完成以及 bug 修复后的代码，可根据需求大小程度确定是由 feature 分支合并，还是直接在上面开发。
一定是满足测试的代码才能往上面合并或提交。
feature 分支
feature 为需求开发分支，命名规则为 feature- 开头，一旦该需求上线，便将其删除。
这么说可能有点不容易理解，接下来举几个开发场景。
开发场景
新需求加入
有一个订单管理的新需求需要开发，首先要创建一个 feature-order 分支，问题来了，该分支是基于哪个分支创建？
如果 存在 未测试完毕的需求，就基于 master 创建。
如果 不存在 未测试完毕的需求，就基于 develop 创建。
- 需求在
feature-order分支开发完毕，准备提测时，要先确定develop不存在未测试完毕的需求，这时研发人员才能将将代码合并到develop（测试环境）供测试人员测试。 - 测试人员在
develop（测试环境） 测试通过后，研发人员再将代码发布到release（预上线环境）供测试人员测试。 - 测试人员在
release（预上线环境）测试通过后，研发人员再将代码发布到master（正式环境）供测试人员测试。 - 测试人员在
master(正式环境) 测试通过后，研发人员需要删除feature-order分支。
普通迭代
有一个订单管理的迭代需求，如果开发工时 < 1d，直接在 develop 开发，如果开发工时 > 1d，那就需要创建分支，在分支上开发。(建议全都新建分支，真实情况下可能由于数据问题，在生产环境有bug，而其他环境无法复现)
开发后的提测上线流程 与 新需求加入的流程一致。
修复测试环境 Bug
在 develop 测试出现了Bug，如果修复工时 < 2h，直接在 develop 修复，如果修复工时 > 2h，需要在分支上修复。(建议全都新建分支，真实情况下可能由于数据问题，在生产环境有bug，而其他环境无法复现)
修复后的提测上线流程 与 新需求加入的流程一致。
修改预上线环境 Bug
在 release 测试出现了 Bug，首先要回归下 develop 分支是否同样存在这个问题。
如果存在，修复流程 与 修复测试环境 Bug 流程一致。
如果不存在，这种可能性比较少，大部分是数据兼容问题，环境配置问题等。
修改正式环境 Bug
在 master 测试出现了Bug，首先要回归下 release 和 develop 分支是否同样存在这个问题。
如果存在，修复流程 与 修复测试环境 Bug流程一致。
如果不存在，这种可能性也比较少，大部分是数据兼容问题，环境配置问题等。
紧急修复正式环境 Bug
需求在测试环节未测试出 Bug，上线运行一段时候后出现了 Bug，需要紧急修复的。
我个人理解紧急修复的意思是没时间验证测试环境了，但还是建议验证下预上线环境。
- 如果
release分支存在未测试完毕的需求，就基于master创建hotfix-xxx分支，修复完毕后发布到master验证，验证完毕后，将master代码合并到release和develop分支，同时删掉hotfix-xxx分支。 - 如果 release 分支不存在未测试完毕的需求，但
develop分支存在未测试完毕的需求，就基于release创建hotfix-xxx分支，修复完毕后发布到release验证，后面流程与上线流程一致，验证完毕后，将master代码合并到develop分支，同时删掉hotfix-xxx分支。 - 如果
release和develop分支都不存在未测试完毕的需求， 就直接在develop分支上修复完毕后，发布到 release 验证，后面流程与上线流程一致。
并行提测
在一个项目中并行开发了两个需求，并行提测，但是上线日期不同。
我能想到的两种方案：
- 再部署一套可供测试人员测试的分支
- 使用
git cherry-pick“挑拣”提交
也可以 featureA 分支上线后，release 上是最新的代码，也可以将 release 分支合并到 featureB分支，防止一些文件在 featureB 分支上线的时候退化了。
Commit 日志规范
提交信息一定要认真填写！
建议参考规范：<type>(scope)：<subject>
比如：fix(首页模块)：修复弹窗 JS Bug。
type 表示 动作类型，可分为：
- fix：修复 xxx Bug
- feat：新增 xxx 功能
- test：调试 xxx 功能
- style：变更 xxx 代码格式或注释
- docs：变更 xxx 文档
- refactor：重构 xxx 功能或方法
scope 表示 影响范围，可分为：模块、类库、方法等。
subject 表示 简短描述，最好不要超过 60 个字，如果有相关 Bug 的 Jira 号，建议在描述中加上。
© 新亮的文章，加粗部分是我写的，当作笔记
最后恰饭 阿里云全系列产品/短信包特惠购买 中小企业上云最佳选择 阿里云内部优惠券
