Git flow 規範
參考文章
Git 在團隊中的最佳實踐--如何正確使用Git Flow
A successful Git branching model
VV採用標準的Git flow，下面將從工作流圖與抽象模型兩個方面，來描述與規範 Git flow。
並在此基礎上給出vv 的 master分支，hotfix-分支，develop分支，release-分支，feat-分支和bugfix-分支的定義與上下文。
工作流圖
1 永久分支：Master分支與Develop分支
1.1 Master分支上的Commit都有對應的Tag。
1.2 Develop分支與Master分支是兩個永久存在的分支，從公Master拉取Develop分支。
1.3 Develop分支不直接合併到Master分支，其通過Release分支合併到Master分支。
1.4 Master分支與線上版本保持一致。
1.5 Develop分支是自動構建分支，它總是保有當前即將發布或是已經發布的代碼，是確定的下一次將要通過Release分支合併到master上的代碼。
2 臨時分支Feature
2.1 當需要開發新的特性時，從Develop分支拉取Feature分支。
2.2 命名規範：
標準Git flow 認為Feature分支可以是，除以master, develop, release-, 和 hotfix-_ 開頭的任何串。
在此我們規定，Feature分支命名規範以feat-開使。
2.3 生命週期：開發中存在，在合併到develop後或是丟棄後，便刪除。
2.4 通常只在開發者的倉庫中存在，origin中沒有Feature分支。（不採納這條限制，多人合作需要Feature上推到origin）
2.5 Feature分支做完後（做完是值完成了主體功能，完成了大部分測試與bug的修復，可以存在少量的非重要bug），確定為當前上線的版本後，便可合併回Develop, 合併完分支後一般會刪點這個Feature分支，也可以保留。
到這裡，一個Feature分支的生命週期便結束了。
3 臨時分支Release
Release分支基於Develop分支創建，可以在Release分支上測試，修改Bug等。
同時，其它開發人員可以基於Develop開發新的Feature (記住：一旦打了Release分支之後不要從Develop分支上合併新的改動到Release分支)
發布Release分支時，合併Release到Master和Develop， 同時在Master分支上打個Tag記住Release版本號，刪除Release分支。
4 臨時分支hotfix
hotfix分支基於Master分支創建，開發完後需要合併回Master和Develop分支，同時在Master上打一個tag
Git Flow 抽象模型
在使用的過程中一定要注意到數據流的流動方向。
下面給出Git Flow 的抽象模型，讓大家能更加直觀的把握、靈活的運用於實踐中。
Feature分支流程
1 當有新的特性需要開發時，從Develop分支拉取Feature分支。
2 Feature分支在經過開發、測試後，確定為當前即將發布版本之後，便可合併到Develop分支，並刪除Feature分支。
3 向Develop分支合併後，創建對應的Release分支，這可以對應一個或是多個Feature。
4 在Release上完成次要bug修復、發版配置等之後，便可合併到Develop與Master（Master上的合併需要加上tag）。
hotfix分支流程 與 release分支流程
1 它們都具有兩個合併分支，Develop分支與Master分支。
2 hotfix拉取於Master分支。
3 release拉取於Develop分支。
4 hotfix是為解決線上嚴重問題而生。
5 release是為特性發布、工程配置、少量bug測試等問題而生。
release過後常規bug修復
release發布前，該特性引入的常規bug是在其上修改的。
對於release發布後，或是其它特性引入的bug，我們引入以"bugfix-"為開頭的新特性。
至此我們基本遵守了標準 Git Flow 開發模型。
做了一個擴充：引入以"bugfix-"為開頭的新特性，支持release發布後在Develop上發現的bug常規bug。
做了一個限制：Feature分支命名規範以「feat-」開始。
完整的數據流圖與命名規範
格式： prename_postname
如 hotfix-5.11 , feat-5.11 , release-5.11 （5.11 為版本或是特性名稱）
bugfix-圖片上傳（針對功能命名） ， bugfix-5.11 （針對某版本或是特性命名）
master分支
master是項目第一個被創建的分支。
每一個向master的合併，都對應一個經過嚴格測試的主觀穩定的線上版本。
它是hotfix-分支的上游分支。
hotfix-分支
當線上版本出現嚴重的bug時，需要從master上選取特定的tag拉取代碼。
在完成測試具備上線條件後，在hotfix-分支上完成版本的發布。
經灰度發布後，先合併到master，再合併到develop分支。
這兩個合併步驟是不可分的，是一個事務。亦可稱為同時合併到master分支和develop分支。
develop分支
develop分支在git flow 中承擔了最為複雜與重要的任務。
它是feat-分支、release-分支，和bugfix-分支的起點。
是代碼的同步中心，其它任何分支，都是經過develop分支完成代碼同步的。
feat-分支
feat-分支是研發分支，源於develop分支，終於develop分支。
在feat-分支完成所有的新功能研發，多少bug的修復與優化工作。
在確定為會在下一個版本發布時，便可以合併到develop分支。
在develop分支上有一個或是多個合併的未上線的feat-分支時，可以選擇拉取release-分支，進入release階段。
release-分支
release-分支承載了發布中項目的配置，一定bug的修復，優化等工作。
創建release-分支有兩個目的：
儘快向develop分支合併確定的下版feat-分支，極大的提高了研發的並發度；
經測試、發布、審核，進入灰度後，直到確定為不再回滾正式發布後，合併到master與develop分支。
它維護了長時間窗口等待期，確保master與線上版本的一致。
bugfix-分支
可被視為特殊的feat-分支。
??????分支操作注意事項
KenChoi：為什麼你應該停止使用 Git rebase 命令
只能對自己的私有分支做rebase操作。
凡涉及到幾大共有分支（master, develop, release-, hotfix-_和 bugfix-）上的commit的合併,
必須使用merge，禁止使用rebase。嚴格禁止共有分支上的提交id變更。
其它分支可以使用rebase，合併到develop分支，但是隻要提交到了develop，
所有的commit就屬於develop分支，禁止再使用rebase操作。
推薦閱讀：
