引言
編寫的目的
-通過規范化的流程，使得產品、開發與測試等各個部門更高效的協同工作。
-通過規范化的流程使得產品高效穩定運行。
背景
在多組員，多項目等環境進行協同工作時，如果沒有統一規范、統一流程，則會導致額外的工作量，甚至會做無用功。所以要減少版本沖突，減輕不必要的工作，就需要規范化的工作流程。
總則
-統一使用Git作為版本控制的主要工具。
-統一使用GitFlow流程管理控制版本。
提交的準則
1.除了源碼相關的東西之外，其他build產生的東西（如：maven的target文件夾，.idea文件夾等），均不能提交進入源碼倉庫，添加到.gitignore文件中忽略掉。
2.撰寫規范的提交說明。一份好的提交說明可以幫助協作者更輕松更有效地配合工作。
3.要嚴格按照我們指定的流程切換到指定分支，開發相應的功能。
分支簡述
我們使用的分支流程：
-天藍色圓點所在的線為我們源碼的主線（master）。
-天藍色方形指向的節點就是每一個發布版本的標簽（tag）。
-紫色圓點所在的線為主要分支線（develop）。
-橙色圓點所在的線為新功能開發分支線（feature）。
-綠色圓點所在的線為新版本發布線（release）。
-紅色圓點所在的線為發布版本bug修復線（hotfix）。
主分支說明
代替原來的單個主線（master），我們使用兩個分支來記錄源碼軌跡：
1.原來的master分支用來記錄官方發布軌跡；
2.新的develop分支是一個集成分支，用來記錄開發新功能的軌跡。
除了master主線和develop主分支線，其他的分支都是臨時的分支，有一定的生命周期的，其余的工作流程分支都是圍繞這兩個分支之間的區別進行的。
其他分支說明
-新功能分支（Feature Branches）
每一個新的功能都應該創建一個獨立的分支，從develop分支中派生出來。當功能完成后，要合并（merged）回develop分支，合并后它的生命周期就結束。新功能分支不會與master分支有直接的交匯。如圖：
注意：對于所有意圖和目的，新功能分支會合并到develop分支。但是，這個Gitflow工作流不會在此結束。
-發布分支（Release Branches）
一旦開發的功能已經滿足發布條件（或預定發布日期接近），應該合并所有滿足發布條件的新功能分支到develop分支中，然后，開出一個發布分支（Release），開始準備一個發布版本。在這個分支上，不能再添加新的功能，只有bug修復和該版本為導向的任務。一旦到了發布日期，Release就要合并回master發布，并且，打出版本標簽。另外，還需要合并回develop分支。
使用一個專門的分支來準備發布版本，使得一個團隊能對當前版本進行拋光，而另一個團隊繼續為下一個版本的功能做準備。它還創造了良好定義的發展階段（例如，很容易說，“本周我們正在準備4.0版”，而且真實地看到它在庫中的結構）。
-維護分支（Maintenance Branches）
維護分支也就是線上bug修復分支，使用來快速修復生產環境的緊急問題。
這個分支是唯一一個開放過程中直接從master分支派生來的分支。快速的修復問題后，它應該被合并回master和develop（或者當前發布分支），然后，master分支需要打一個版本標簽。
一個專門的錯誤修復開發線，可以讓團隊在不等待下一個發布周期，導致中斷工作流程情況下解決問題。可以將維護分支當做主要的問題修復分支，與master并行。
命名約定
-主分支名稱：master
-主開發分支名稱：develop
-標簽（tag）名稱：v*.RELEASE，其中”*“ 為版本號，“RELEASE”大寫，如：v1.0.0.RELEASE
-新功能開發分支名稱：feature-*or feature/*，其中“*” 為新功能簡述，如：feature-item-activity-list
-發布分支名稱：release-*or release/*，其中*為版本號，“release”小寫，如：release-1.0.0
-master的bug修復分支名稱：hotfix-*or hotfix/*，其中*為bug簡述，如：hotfix/item-update-bug
工作流程
下面具體演示如何使用工作流來管理版本發布周期。假設我們已經存在或創建了一個源碼中央存儲倉庫。
工作流的基礎
創建develop分支
-項目負責人在本地master基礎上創建一個develop分支，然后，推送到服務器；
git branch develop
git push -u origin develop
-其他開發人員，需要克隆develop中央倉庫的源碼，創建一個develop的軌跡版本；如果，已經克隆過該項目，則，不需要執行以下第一條命令。
git clone git@github.org:search-cloud/demo.git
git checkout -b develop origin/develop
develop這個分支將包含項目的完整歷史記錄，而master將包含縮略版本。
** 假設開始以下所有的流程之前，都已經創建好develop分支。**
新功能開發流程
1.新建feature分支
基于develop分支創建新功能分支：
git checkout -b feature/demo develop
推送到遠程倉庫，共享：
git push
所有開發此新功能的人員，都在此分支上開發提交代碼。
git status
git add
git commit -m "Add some-file."
2.完成新功能開發（合并feature分支到develop）
當確定新功能開發完成，且聯調測試通過，并且新功能負責人已經得到合并feature分支到develop分支的允許；這樣才能合并feature分支到develop。
git pull origin develop
git checkout develop
git merge feature/demo
git push
git branch -d feature/demo
第一條命令是確保在合并新功能之前，develop分支是最新的。
注意：
-新功能分支，永遠不要直接合并到master分支。
-合并可能會有沖突，應該謹慎處理沖突。
3.在測試環境發布develop分支代碼（提交測試）
線上版本發布流程
1.從develop中創建準備發布的release分支
當主測試流程完成，源碼已經趨近于穩定狀態，應該準備一個發布版本，確立版本號：
git checkout -b release-0.1.0 develop
推送到遠程倉庫共享：
git push
這個分支是清理準備發布、 整體回歸測試、 更新文檔，和做其他任何系統即將發布的事情。
2.繼續拋光改bug
3.release分支合并到master發布
一旦已經滿足發布條件（或已經到了預定發布日期），應該把release分支合并到master分支和develop分支中，然后，使用master發布新版本。合并release分支到develop分支是很重要的，要讓release上修改的東西能在后續的開發分支中生效。
git checkout master
git merge release-0.1.0
git push
4.release分支合并到develop
git checkout develop
git merge release-0.1.0
git push
git branch -d release-0.1.0
5.打標簽
Release分支在功能開發分支（develop）和公共發布版（master）中，充當一個緩沖的作用。每當有源碼合并到master中的時候，應該在master上打一個標簽，以便后續跟蹤查閱。
git tag -a 0.1.0.RELEASE -m "Initial public release" master
git push --tags
線上Bug修復流程
當終端用戶，反饋系統有bug時，為了處理bug，需要從master中創建出保養分支；等到bug修復完成，需要合并回master：
1.創建hotfix分支
git checkout -b issue-#001 master
2.修改bug Fix the bug
3.完成修復，合并到master發布
git checkout master
git merge issue-#001
git push
4.打標簽
git tag -a 0.1.1.RELEASE -m "Initial public release" master
git push --tags
5.合并到develop
git checkout develop
git merge issue-#001
git push
