热修复版本分支策略

引入热修复分支管理

引入热修复技术以后，为了更好地进行分支管理，我们有必要引入一个fix分支，因此分支有以下几种：

1. master分支：这是一个主干分支，同时也是稳定分支，上面不能有commit，但是可以有tag，通常来说代码都是merge过去的。
2. dev分支：开发分支，专门用于开发新功能的、修复BUG等的分支，代码由个人分支merge过来。每次发布新版本之后，都需要利用master分支进行覆盖。
3. 个人分支：个人开发分支。
4. fix分支：专门用于管理线上BUG热修复的。

热修复流程

没有引入热修复的时候，版本的管理策略比较简单：

image.png

引入热修复之后，不同版本之间，还插入了一个动态更新的版本：

image.png

热修复技术除了修复BUG，还可以上一些节日小功能。

下面以线上BUG修复为例，相关的发版与线上BUG修复流程如下：

1. 个人开发分支向dev分支合并
2. dev分支测试验证通过
3. dev分支向master分支进行合并，并且打tag，版本发布
4. 线上出现BUG了
5. 将当前稳定版的master分支向fix分支进行合并，然后修复对应的BUG
6. 测试验证通过
7. 将相应的提交合并到master分支
8. 生成相应Patch文件，交给服务器
9. 用户APP请求服务器，下载、安装Patch，重启，修复BUG
10. 下一个迭代开始，将master分支合并到dev分支（此时线上BUG的修复提交已经在里面了），个人分支拉取dev分支，进行开发
11. 最后重复1过程

一般来说，都是月初发版、月中发布补丁版本，其中，没有BUG的话补丁版本可以没有。

引入热修复之后需要注意的问题

引入热修复之后并不就见得是高枕无忧了，需要注意的问题有以下：

1. 依然是强调代码质量，不能过分依赖热修复技术
2. 热修复技术的发版应该要跟正常的发版一样严格，都需要经过严格的测试验证
3. 版本之间最好有一个补丁版本