git 在工做中的使用以及與git flow比較

描述：

1. 最穩定的代碼放在 master 分支上（至關於 SVN 的 trunk 分支），咱們不要直接在 master 分支上提交代碼，只能在該分支上進行代碼合併操做，例如將其它分支的代碼合併到 master 分支上。
2. 咱們平常開發中的代碼須要從 master 分支拉一條 develop 分支出來，該分支全部人都能訪問，但通常狀況下，咱們也不會直接在該分支上提交代碼，代碼一樣是從其它分支合併到 develop 分支上去。
3. 當咱們須要開發某個特性時，須要從 develop 分支拉出一條 feature 分支，例如 feature-1 與 feature-2，在這些分支上並行地開發具體特性。
4. 當特性開發完畢後，咱們決定須要發佈某個版本了，此時須要從 develop 分支上拉出一條 release 分支，例如 release-1.0.0，並將須要發佈的特性從相關 feature 分支一同合併到 release 分支上，隨後將針對 release 分支部署測試環境，測試工程師在該分支上作功能測試，開發工程師在該分支上修改 bug。
5. 待測試工程師沒法找到任何 bug 時，咱們可將該 release 分支部署到預發環境，再次驗證之後，均無任何 bug，此時可將 release 分支部署到生產環境。
6. 待上線完成後，將 release 分支上的代碼同時合併到 develop 分支與 master 分支，並在 master 分支上打一個 tag，例如 v1.0.0。
7. 當生產環境發現 bug 時，咱們須要從對應的 tag 上（例如 v1.0.0）拉出一條 hotfix 分支（例如 hotfix-1.0.1），並在該分支上作 bug 修復。待 bug 徹底修復後，需將 hotfix 分支上的代碼同時合併到 develop 分支與 master 分支。

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

與Git Flow模型分支管理的區別點：

• feature分支開發完成後，暫時不合並至develop，而是基於develop開啓release分支，將feature分支合併到release分支，進行測試；
• release分支測試經過後，部署到生產環境，將release分支代碼合併到develop分支與master分支，並在master分支打一個tag；