【0156】【热修复与插件化-4】引入热修复后代码及版本管理

1.代码分支管理

【内容提要】

1.1 代码分支管理

【说明】

【1】在没有引入热修复的时候，使用到的分支管理如下；

【2】master分支（一直存在）、dev分支（一直存在）；其他分支（各种开发人员的分支，开发结束之后就可以删除）

【3】【注意1】master分支：只能进行代码的合并和dev分支的merge和branch，不能存在代码的commit操作，即不能存在代码的提交和修改；

原因：有些开发者直接在master修改，忘记将master的修改同步到dev的分支，在下一个版本开发的时候，dev分支和master的代码不一致，master的修改就会被下一次的dev提交覆盖掉；

master所有的分支都是从dev分支合并过去的；

【注意2】在dev分支开发代码的时候，必须保证dev分支的代码与master的代码是一致的；原因是防止开发人员在master上commit代码；

1.2 增加动态更新之后的分支

【说明】在远程仓库都具有三个分支，master：管理线上的代码；dev：管理所有版本开发的代码；hotfix：管理动态更新的代码；

【开发普通的功能】在dev上开发，开发结束之后测试、打包之后上线，上线之后将代码合并到master中，然后再master上打一个对应版本的tag；

【动态版本的更新】在hotfix上开发，在hotfix下生成和发布patch文件，最后将hotfix的代码合并到master上；同时也打一个tag；

  在实际的开发中，补丁版本和应用市场的发布是做等同处理的；

 

 1.3 三个分支的配合工作

 【使用软件sourceTree】【下载地址】https://www.sourcetreeapp.com/

1.3.1 正常代码的提交

【实战】现在只有master、dev、hot_fix 三个分支；现在改动代码，留下一个小bug，给hot_fix修复提交：

1.3.2 动态更新修复bug

【说明】在hotfix修改代码的时候一定记得将master的代码同步到hotfix中；

【==========================生成patch文件=======参考前面的章节==================================================================】

【打tag的版本号】正式发布的版本是3位，hotfix使用的是4位，前面的3位是正式发布的修改的版本；

2.版本节奏管理

3.总结