加入动态更新后如何管理我们的代码分支
一般的解决方式
master：线上分支，用来存放线上代码
dev ：开发分支
micael 和 bob ：个人分支
一般的流程就是首先是个人开发，功能完成后合并到 dev。测试通过后进行发布，发布后在 dev 上创建一个 tag ，记录一下版本号如 V1.0.0，然后后将dev分支合并到master分支。 发布完成后 michael 和 bob 会被删除掉。如果有新的功能要实现，则会冲 dev 新建个人分支来进行开发。
注意：不能再 master 分支上进行任何开发和提交。master 上的代码都应该是从 dev 进行合并的。如果修改了master 进行发布，但是忘了同步到 dev。到下一个版本从 dev 合并到 master 时就会出现问题。
每次在dev 开发新功能是必须确保 dev 和 master 上的代码时一致的。
动态更新后如何管理分支
除了 master 和 dev，引入 fix 分支，专门用来管理动态更新迭代
如果线上版本出了问题，就使用 fix 分支进行修复，大致流程如下
1，将 master 分支代码全部合并到 fix 分支，保证 fix 和 master 代码一致
2，在 fix 修复bug。生成 补丁文件。
3，将 fix 代码合并到 master 中。合并后 master 上就不会有 bug 了。
4，下发补丁文件，接着在 fix 分支创建一个 tag。一般情况下 tag 上的版本是 3 位的。但是入过是动态更新的，我们可以将 tag 改为 4 位，如 V1.0.0.1 ,最后的 1 就代表在 1.0.0 版本的基础上动态更新了一次。这样就会方便查看。
5，将master 代码合并到 dev 中，保证 master 和 dev 一致。
加入动态更新后如何管理我们的发版节奏
以前的版本迭代
加入动态版本迭代后
发布版本后，这个版本如果这某些机型上有兼容性问题或者是有 bug 了。这个时候就要动态的进行修复。注意 两个版本直接最好只有一次动态更新。
注意问题
一定要提高代码质量，而不是过分依赖于动态更新
动态更新的发版要与应用市场一样严肃对待
应用市场发版节奏之间最好只有一个动态更新版本，最多不要超过3个。
动态更新的发版要与应用市场一样严肃对待
应用市场发版节奏之间最好只有一个动态更新版本，最多不要超过3个。
