引入热修复分支管理
引入热修复技术以后，为了更好地进行分支管理，我们有必要引入一个fix分支，因此分支有以下几种：
- master分支：这是一个主干分支，同时也是稳定分支，上面不能有commit，但是可以有tag，通常来说代码都是merge过去的。
- dev分支：开发分支，专门用于开发新功能的、修复BUG等的分支，代码由个人分支merge过来。每次发布新版本之后，都需要利用master分支进行覆盖。
- 个人分支：个人开发分支。
- fix分支：专门用于管理线上BUG热修复的。
热修复流程
没有引入热修复的时候，版本的管理策略比较简单：
image.png
引入热修复之后，不同版本之间，还插入了一个动态更新的版本：
image.png
热修复技术除了修复BUG，还可以上一些节日小功能。
下面以线上BUG修复为例，相关的发版与线上BUG修复流程如下：
- 个人开发分支向dev分支合并
- dev分支测试验证通过
- dev分支向master分支进行合并，并且打tag，版本发布
- 线上出现BUG了
- 将当前稳定版的master分支向fix分支进行合并，然后修复对应的BUG
- 测试验证通过
- 将相应的提交合并到master分支
- 生成相应Patch文件，交给服务器
- 用户APP请求服务器，下载、安装Patch，重启，修复BUG
- 下一个迭代开始，将master分支合并到dev分支（此时线上BUG的修复提交已经在里面了），个人分支拉取dev分支，进行开发
- 最后重复1过程
一般来说，都是月初发版、月中发布补丁版本，其中，没有BUG的话补丁版本可以没有。
引入热修复之后需要注意的问题
引入热修复之后并不就见得是高枕无忧了，需要注意的问题有以下：
- 依然是强调代码质量，不能过分依赖热修复技术
- 热修复技术的发版应该要跟正常的发版一样严格，都需要经过严格的测试验证
- 版本之间最好有一个补丁版本
