https://blog.csdn.net/iprettydeveloper/article/details/53944125
倉庫的分支(Branch)規(guī)范，影響到每個(gè)團(tuán)隊(duì)的工作流的一致性；標(biāo)簽(Tag)便于開發(fā)團(tuán)隊(duì)、測(cè)
試團(tuán)隊(duì)和其他團(tuán)隊(duì)識(shí)別每個(gè)項(xiàng)目的版本，特別是在協(xié)同處理線上問題的時(shí)候，大家可以非常清楚
地知道線上運(yùn)行版本和代碼庫的對(duì)應(yīng)關(guān)系。因此我們?cè)谥谱鞯臅r(shí)候，主要考慮幾個(gè)因素：
- 一是要有一定的規(guī)則，方便持續(xù)集成CI（自動(dòng)化構(gòu)建、測(cè)試、分布等）
- 二是要有一定的自由度，以適應(yīng)不同團(tuán)隊(duì)的內(nèi)部協(xié)作靈活性
- 要清晰規(guī)整，不要參差不齊難以識(shí)別
基于我們當(dāng)前團(tuán)隊(duì)的協(xié)作能力和提交代碼的質(zhì)量水平，并考慮方便持續(xù)集成CI（自動(dòng)化構(gòu)建、
測(cè)試、發(fā)布），我們約定下列常駐Branch：
-
develop 分支：顧名思義即持續(xù)開發(fā)的分支，我們希望每個(gè)開發(fā)組都在這個(gè)分支上保
持線性的持續(xù)小步迭代，正常的CodeReview WorkFlow和開發(fā)級(jí)的自動(dòng)CI也在這里進(jìn)行。
當(dāng)開發(fā)完一個(gè)迭代(Sprint)，開發(fā)小組有信心轉(zhuǎn)測(cè)時(shí)，就將代碼合并到 release 分支，
并要求打一個(gè)alpha級(jí)的Tag(如5.2.0-alpha) -
release 分支：顧名思義即用于發(fā)布過程的分支，包括開發(fā)轉(zhuǎn)測(cè)(實(shí)際上我們認(rèn)為這里的測(cè)試集成測(cè)試)、測(cè)試和BugFix以及發(fā)布上線的過程，當(dāng)發(fā)布成功時(shí)要打一個(gè)發(fā)布beta Tag(如
5.2.1-beta)，并將代碼合并到 master 分支 -
master 分支：即有質(zhì)量保證的、可安全運(yùn)行的分支，禁止直接代碼提交，避免被污染，僅用
于代碼合并和歸集，在這個(gè)分支上的代碼應(yīng)該永遠(yuǎn)是可用的、穩(wěn)定的。當(dāng)需要拉一個(gè)特別的開發(fā)分時(shí)，
應(yīng)該基于 master。
當(dāng)需要fix線上的一個(gè)問題是，應(yīng)該基于上線時(shí)的那個(gè)beta Tag做hotfix。當(dāng)出現(xiàn)線上Bug需要hotfix時(shí)，我們需要在上次上線的Tag處拉一個(gè)臨時(shí)的 hotfix 分支進(jìn)行
修正，或者在未被其他開發(fā)迭代污染的release分支上直接hotfix上線并合并到master和
develop，然后打一個(gè)新的Tag(如5.2.2-beta）
這個(gè)分支體系是我們期望長(zhǎng)期持續(xù)迭代的分支規(guī)劃，其它臨時(shí)分支的刪除、創(chuàng)建、命名，都由團(tuán)隊(duì)自己
決定，保持一定的靈活性。但每個(gè)團(tuán)隊(duì)都應(yīng)該努力避免對(duì)上述常規(guī)情況造成破壞的情況發(fā)生，如果有特
殊情況（如有兩個(gè)并行的開發(fā)分支同步進(jìn)行），需要由各組Leader和QA團(tuán)隊(duì)協(xié)商提供臨時(shí)方案，這會(huì)
影響到團(tuán)隊(duì)協(xié)同中的轉(zhuǎn)測(cè)、CI基準(zhǔn)分支等。
關(guān)于打 Tag 的規(guī)則 ：
鼓勵(lì)開發(fā)和QA團(tuán)隊(duì)共同對(duì)勤于打Tag，這便于真正的版本管理，避免有rollback需要或者需要查看和
對(duì)比歷史版本的時(shí)候的混亂和低效局面。但同時(shí)也要求一定的規(guī)范性，讓人一看便知。
Tag格式為： MajorVersion.MinorVersion.FixVersion-TypeLabel，其中TypeLabel
為 alpha、 beta、 devel。具體參見下圖舉例，其中devel是留給開發(fā)過程中
使用的。
分工上，開發(fā)團(tuán)隊(duì)負(fù)責(zé)打 tag-alpha，測(cè)試團(tuán)隊(duì)負(fù)責(zé)打 tag-beta。
但是，自己決定并不意味著胡亂命名，大家仍然要以 語義明（白）（準(zhǔn)）確 的原則
來管理自己的分支和標(biāo)簽名，因?yàn)樗羞@些都是為了提高協(xié)作效率。
這是一個(gè)參考示意圖：
事實(shí)上，上圖和常用的 Git 分支實(shí)踐是比較相似的，只是為了方便自動(dòng)化工作，我們將 release 分支常駐并配合 tag 管理了，其他工作的 workflow 基本相似，如下圖：
