最穩定的代碼放在 master 分支上（相當于 SVN 的 trunk 分支），我們不要直接在 master 分支上提交代碼，只能在該分支上進行代碼合并操作，例如將其它分支的代碼合并到 master 分支上。

我們日常開發中的代碼需要從 master 分支拉一條 develop 分支出來，該分支所有人都能訪問，但一般情況下，我們也不會直接在該分支上提交代碼，代碼同樣是從其它分支合并到 develop 分支上去。

當我們需要開發某個特性時，需要從 develop 分支拉出一條 feature 分支，例如 feature-1 與 feature-2，在這些分支上并行地開發具體特性。

當特性開發完畢后，我們決定需要發布某個版本了，此時需要從 develop 分支上拉出一條 release 分支，例如 release-1.0.0，并將需要發布的特性從相關 feature 分支一同合并到 release 分支上，隨后將針對 release 分支部署測試環境，測試工程師在該分支上做功能測試，開發工程師在該分支上修改 bug。待測試工程師無法找到任何 bug 時，我們可將該 release 分支部署到預發環境，再次驗證以后，均無任何 bug，此時可將 release 分支部署到生產環境。待上線完成后（注：一般master對應著發布版本，應從master發布），將 release 分支上的代碼同時合并到 develop 分支與 master 分支，并在 master 分支上打一個 tag，例如 v1.0.0。

當生產環境發現 bug 時，我們需要從對應的 tag 上（例如 v1.0.0）拉出一條 hotfix 分支（例如 hotfix-1.0.1），并在該分支上做 bug 修復。待 bug 完全修復后，需將 hotfix 分支上的代碼同時合并到 develop 分支與 master 分支。

對于版本號我們也有要求，格式為：x.y.z，其中，x 用于有重大重構時才會升級，y 用于有新的特性發布時才會升級，z 用于修改了某個 bug 后才會升級。針對每個微服務，我們都需要嚴格按照以上開發模式來執行。

針對每個服務的開發工作，我們都需要嚴格按照以上開發規范來執行。

實際上，我們使用的開發規范是業界知名的 Git Flow，可通過以下博客地址了解 Git Flow 的詳細過程：

http://nvie.com/posts/a-successful-git-branching-model/。

摘自：https://blog.csdn.net/penker_zhao/article/details/51132514