Git 项目分支管理

分支管理

创建项目时，会针对不同环境创建两个常设分支(也可以算主分支，永久不会删除)

1. master：生产环境的稳定分支，生产环境基于该分支构建。仅用来发布新版本，除了从release测试分支或 hotfix-*Bug 修复分支进行 merge，不接受任何其它修改。

   master 分支上存放的应该是随时可供在生产环境中部署的代码（Production Ready state）。当开发活动告一段落，产生了一份新的可供部署的代码时，master 分支上的代码会被更新。同时，每一次更新，最好添加对应的版本号标签。

2. develop：开发环境的稳定分支，公共开发环境基于该分支构建，develop分支是保存当前最新开发成果的分支。也就是说develop分支来源于feature、release、hotfix-*分支。

平时开发工作中，会根据需要由开发人员创建四类临时分支(也可以算辅助分支，用完立即删除)

1. feature-*：功能分支，是为了开发某个特定功能，从develop分支上面分出来的。开发完成后，要 merge 到 develop分支。功能分支的命名，采用feature-*的形式命名(*为任务单号)
2. release：测试环境的稳定分支，本分支是从develop分支派生出来的，测试人员在该分支进行测试并提交 Bug,开发人员基于该分支派生的bugfix-*分支进行 bug 修复，最终再合并回release分支，待测试完成，该分支必须合并回develop分支和master分支。
3. bugfix-*：测试阶段修复 Bug 用此类分支命名，该分支是为了修复某个 bug，从release分支上面分出来的。修复完成后，再合并回release分支。Bug 修复分支的命名，采用bugfix-*的形式命名（*为 bug 单号）
4. hotfix-*：线上出现的紧急 Bug，需要及时修复用此类分支命名，从master分支切换出来的分支，修复之后合并回master和develop。

流程规范

正常开发流程

1. 从develop分支切出多个命名为feature-*分支开发新功能。
2. 开发者完成开发，提交分支到远程仓库。
3. 开发者发起 merge 请求（可在 gitlab 页面“New merge request”），将新分支请求 merge 到develop分支，并提醒 code reviewer 进行 review
4. code reviewer 对代码 review 之后，若无问题，则接受 merge 请求，新分支 merge 到develop分支，同时可删除新建分支；若有问题，则不能进行 merge，可 close 该请求，同时通知开发者在新分支上进行相应调整。调整完后提交代码重复 review 流程。
5. 转测时，直接从当前develop分支 merge 到release分支，重新构建测试环境完成转测。
6. 测试完成后，从release分支 merge 到master分支，基于master分支构建生产环境完成上线。并对master分支打 tag，tag 名可为 v1.0.0_2019032115（即版本号_上线时间）

生产环境 Bug 修复流程

生产环境的 Bug 分两种情况：

1. 紧急 Bug：严重影响用户使用的为紧急 Bug，需立即进行修复。如关键业务流程存在问题，影响用户正常的业务行为。
2. 非紧急 Bug 或优化：非关键业务流程问题，仅影响用户使用体验，或出现频率较小等，为非紧急 Bug，可规划到后续版本进行修复。

第二种情况非紧急 Bug 修复参考“正常开发流程”。

第一种紧急 Bug 修复，需要从master分支切出一个 bug 修复分支，完成之后需要同时 merge 到master分支与 develop分支（如果需要测试介入验证，则可先 merge 到release分支，验证通过后再 merge 到master分支上线）。merge 时参考“正常开发流程”。