开发流程与版本管理规范（下）

紧急修复分支

起源分支： master

合并对象分支: develop 和 master

命名规则： hotfix-*

紧急修复分支跟 release 分支类似，都是为发布版本准备的。当线上生成环境有重大的 bug 需要紧急修复，而此时 develop 分支还不稳定，无法发布，我们在 master 分支基础上创建一个 hotfix 分支， 修复 bug 后合并到 master ，再发布到生成环境。

// 命名规则建议为 hotfix-*, * 为当前的 master 的 tag 版本号
git checkout -b hotfix-1.2.35 master

git commit -m "Fixed severe production problem"

git push

hotfix 分支提交后，经代码审核合并到 master 分支, 打上 tag 就可以推送到生成环境了

// 切换到 master 分支
git checkout master

// 合并
git merge --no-ff hotfix-1.2.35

// 更新 tag 版本号，准备推送到生成环境
git tag -a hotfix-1.2.36

除了合并到 master 分支， 还需要合并到 develop 分支， 这样 develop 也包含了针对 bug 的修改。` 如果此时存在 release 版本， 应该合并到 release 分支，而不是 develop 分支，这样下一次发布会包含对 bug 的修改。 release 分支最终也会被合并到 develop 分支。 `

git checkout develop
git merge --no-ff hotfix-1.2.35

bug 修复了 hotfix 分支就可以删除了

git branch -d hotfix-1.2.35

三.如何保障代码质量

开发过程中我们采用自动化的单元测试与人工代码审查相结合的方式来保障代码质量

目前这两项工作刚开始实施，需要一段时间磨合团队。

单元测试

编写单元测试代码， 利用 Git pre-push hook 在推送前自动运行单元测试。未通过单元测试将会中断推送。某些情况下可能因为开发人员的 git hooks 配置错误，造成代码未通过单元测试，也被推送到了服务器。 代码提送到服务器后， 持续集成工具自动拉取最新的代码，再次运行单元测试，测试失败的代码会被标注出来。

代码审查

往代码库的 develop, release, master 分支合并分支前，必须对修改进行审查。

四.测试发布流程

产品发布分为两种：

1. Bug 修复或优化
2. 功能特性发布

Bug 修复或者优化发布频率会很高，1~2 天一次。 测试每次验证已修复的bug，产品确认修改完成，测试提起发版本请求，记录修复的bug，存在的问题（不影响本次发布），并确认存在问题的修改意见。请求通过先发布到预生产环境，在预生产环境中再次测试，确认没有影响版本发布的问题，产品发布到生产环境。如果存在影响发布的问题，立即终止本次发布，修改存在的问题，再次测试，提起发布流程。 这种版本的主版本号和次版本号不会发生变化，只有 build number 会增大。

功能特性的发布事先制定计划，有相应的里程碑管理。测试根据相应的时间点进行功能测试和系统测试，确认没有影响发布的bug，记录存在的问题（不影响发布），并确认存在问题的修改意见。测试此时提起发布版本的请求。请求通过先发布到预生产环境，再次进行完整的测试。确认没有影响版本发布的问题，产品发布到生产环境。如果存在影响发布的问题，立即终止本次发布，修改存在的问题，再次测试，提起发布流程.

Bug 管理

Bug 按严重程度分三个等级

1. 关键， 关键类 bug 影响线上主体业务流程， 必须当天修复。
2. 重要， 重要类的 bug 必须在提出 bug 当天有开发者确认，并设置修复时间。
3. 一般， 提出bug 2天内，开发者确认并设置修复时间