轉Git倉庫分支(Branch)和標籤(Tag)

倉庫的分支(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 基本類似，以下圖：