加入動態更新後如何管理我們的代碼分支
一般的解決方式
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個。
參考：慕課網視頻