倉庫的分支(Branch)規範，影響到每個團隊的工作流的一致性；標籤(Tag)便於開發團隊、測試團隊和其他團隊識別每個項目的版本，特別是在協同處理線上問題的時候，大家可以非常清楚地知道線上運行版本和代碼庫的對應關係。因此我們在製作的時候，主要考慮幾個因素：
- 一是要有一定的規則，方便持續集成CI（自動化構建、測試、分佈等）
- 二是要有一定的自由度，以適應不同團隊的內部協作靈活性
- 要清晰規整，不要參差不齊難以識別
基於我們當前團隊的協作能力和提交代碼的質量水平，並考慮方便持續集成CI（自動化構建、
測試、發佈），我們約定下列常駐Branch：
-
develop 分支：顧名思義即持續開發的分支，我們希望每個開發組都在這個分支上保
持線性的持續小步迭代，正常的CodeReview WorkFlow和開發級的自動CI也在這裏進行。
當開發完一個迭代(Sprint)，開發小組有信心轉測時，就將代碼合併到 release 分支，
並要求打一個alpha級的Tag(如5.2.0-alpha) -
release 分支：顧名思義即用於發佈過程的分支，包括開發轉測(實際上我們認爲這裏的測試集成測試)、測試和BugFix以及發佈上線的過程，當發佈成功時要打一個發佈beta Tag(如
5.2.1-beta)，並將代碼合併到 master 分支 -
master 分支：即有質量保證的、可安全運行的分支，禁止直接代碼提交，避免被污染，僅用
於代碼合併和歸集，在這個分支上的代碼應該永遠是可用的、穩定的。當需要拉一個特別的開發分時，應該基於 master。
當需要fix線上的一個問題是，應該基於上線時的那個beta Tag做hotfix。當出現線上Bug需要hotfix時，我們需要在上次上線的Tag處拉一個臨時的 hotfix 分支進行修正，或者在未被其他開發迭代污染的release分支上直接hotfix上線併合併到master和develop，然後打一個新的Tag(如5.2.2-beta）
這個分支體系是我們期望長期持續迭代的分支規劃，其它臨時分支的刪除、創建、命名，都由團隊自己決定，保持一定的靈活性。但每個團隊都應該努力避免對上述常規情況造成破壞的情況發生，如果有特殊情況（如有兩個並行的開發分支同步進行），需要由各組Leader和QA團隊協商提供臨時方案，這會影響到團隊協同中的轉測、CI基準分支等。
關於打 Tag 的規則 ：
鼓勵開發和QA團隊共同對勤於打Tag，這便於真正的版本管理，避免有rollback需要或者需要查看和
對比歷史版本的時候的混亂和低效局面。但同時也要求一定的規範性，讓人一看便知。
Tag格式爲： MajorVersion.MinorVersion.FixVersion-TypeLabel，其中TypeLabel
爲 alpha、 beta、 devel。具體參見下圖舉例，其中devel是留給開發過程中
使用的。
分工上，開發團隊負責打 tag-alpha，測試團隊負責打 tag-beta。
但是，自己決定並不意味着胡亂命名，大家仍然要以 語義明（白）（準）確 的原則
來管理自己的分支和標籤名，因爲所有這些都是爲了提高協作效率。
這是一個參考示意圖：
事實上，上圖和常用的 Git 分支實踐是比較相似的，只是爲了方便自動化工作，我們將 release 分支常駐並配合 tag 管理了，其他工作的 workflow 基本相似，如下圖：
