前提
基於本地已創建git 項目
分支管理
1 VCS--->Git----> Branches
2 創建新分支或者選擇本地已有分支
3 編輯器右下角可以快速創建分支以及切換分支
標簽管理
1 VCS--->Git----> Tag
2 在Version Contral中右鍵選中一個提交歷史可以創建分支或者標簽
3 同步到git版本服務器
VCS--->Git----> Push
選中 push tags ALL
4 在服務器端可以查看到標簽以及分支
參考
倉庫的分支(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 基本相似，如下圖：
這里寫圖片描述
必讀經典：A successful Git branching model
參考文章：GIT分支管理是一門藝術
參考：https://blog.csdn.net/iprettydeveloper/article/details/53944125