客戶端Git使用規範
1、origin/master是其 HEAD源代碼總是代表了生產環境準備就緒的狀態的主分支；
2、origin/develop是其 HEAD源代碼總是代表了最後一次交付的可以趕上下一次發佈的狀態的主分支，也把它叫做“集成分支”；
3、每當 develop分支到達一個穩定的階段，可以對外發布時，所有的改變都會被合併到 master分支，並打一個發佈版本的 tag；
一、分支管理規範
原則
- 每個項目，必須存在master和develop兩個分支，develop是基於master開出的集成分支。
- 保持develop分支只能合併，不能開發原則。
- 保持master分支只能合併，不能開發原則。
開發階段分支管理
1、業務需求開始開發時，基於develop開出新分支（不允許在develop上面寫代碼），命名爲version-demand-productType。
1.1：如4.17.0-demand-product，提測時，測試的是該分支包。
1.2：修復開發中的bug，在對應的分支上修改，修改完畢後並提測該分支。
1.3：測試相應分支完畢後，及時將該對應分支合併到develop分支。
2、技術需求開始開發時，基於develop開發新分支，命名爲version-tech-feature。
2.1：如4.17.0-tech-memory，提測時，測試的是該分支。
2.2：測試相應分支完畢後，及時將該對應分支合併到develop分支。
3、提測期間，打包基於各自的工程分支。
預上線階段分支管理
1、預上線時，各自業務端，將本期即要上線所開的分支，合併到對應的develop分支。
2、預上線若有bug修復
3.1：在各自工程的當前分支修復當前bug，並在測試環境，測試bug是否修復。（如若不需要驗證，直接走3.2）
3.2：若bug已修復，再次合併到各自工程的develop分支，通過打殼工程包繼續驗證。
4、預上線期間，打包基於殼工程的當前版本開發分支。
上線發包階段分支管理
1、各自工程的develop分支，合併到master分支，並打好tag。命名爲version版本號。tag即4.17.0
1.1：刪除各自業務工程本地開發的所有branch分支。
2、測試基於develop分支打出的包進行驗證迴歸。
5、發包後，如若存在bug修復
5.1：（可認爲屬測試階段）從當前業務的develop開出分支，命名爲version-bugfix-feature。如4.17.0-bugfix-login，基於當前分支進行打包測試。
5.2：（可認爲屬預上線階段）上述步驟測試完畢後，各自工程合併到對應的develop分支，然後基於殼工程當前版本的開發分支進行打包，然後繼續測試。（如若不需要驗證，直接走5.3）
5.3：（屬於發包階段）上述步驟測試完畢後，將develop分支合併到master，並打出修復tag。基於原來的tag打出一個小version版本號。tag即4.17.1.
5.4：（屬於發包階段）重複發包階段分支管理各個階段，打包驗證迴歸。
包發佈到市場後的分支管理
1、將殼工程當前的develop分支，合併到master分支，並打好tag。命名爲version版本號。tag即4.17.0
2、如若發包到市場後存在bug修復
3.1：基於各自工程的master的tag分支，開出bug修復分支。命名爲version-bugfix-feature，如4.17.0-bugfix-login，基於當前分支進行打包測試。
3.2：上述步驟測試完畢後，將該修復分支合併到master，並打出修復tag。基於原來的tag打出一個小version版本號。tag即4.17.2。
3.4：上述步驟測試完畢後，發佈市場後，將該修復分支合併到master分支，命名爲version版本號。tag即4.17.2。並刪除本地修復的版本分支。
tag管理
1、打tag值時，一定遵循附註標籤方式，即git tag -a 1.0.0 -m “some commit info”
二、命名規範
1、產品需求分支命名規範：version-demand-productType.
例：4.17.0-demand-product 或4.17.0-demand-universalLinks
2、技術需求分支命名規範：version-tech-feature
例：4.17.0-tech-memory
3、bug修復分支命名規範：version-bugfix-feature
例：4.17.0-bugfix-login
4、tag命名規範：version
例：4.17.0 、4.17.1等