倉庫的分支(Branch)規(guī)范，影響到每個團(tuán)隊的工作流的一致性與工作效率。我們在實(shí)際工作中使用Git做代碼管理工具時，經(jīng)常會遇到這種情況：項目需要穩(wěn)步迭代升級的同時，定制化的需求與項目便接憧而至。合理的使用Git不僅可以簡化繁雜的研發(fā)工作，同時也可以提升QA，PM，OP等團(tuán)隊之間的協(xié)同效率。而過度的“自由”，“無序”則是一切災(zāi)難的開始......
1、Git代碼庫分類
根據(jù)代碼庫分布的位置及作用，可分為以下三類：
- 主庫：位于服務(wù)端（如github、gitee等），所有開發(fā)的代碼最終都要合到主庫。
- 個人代碼庫：位于服務(wù)端（如github、gitee等），從主庫fork出來。每位研發(fā)人員自已負(fù)責(zé)自己的代碼，由本地的git庫push到個人代碼庫，再由個人代碼庫合入主庫。
- 個人工作庫：位于每個研發(fā)人員的本地開發(fā)機(jī)器上，代碼從個人代碼庫clone到本地。每位研發(fā)人員開發(fā)的代碼，先commit到個人工作庫，再由個人工作庫push到個人代碼庫。
2、Git人員角色分類
該小節(jié)中提及的角色，都是作用于主庫上的?；诤喕脑瓌t，人員分為三類：
- Owner：擁有主庫的所有權(quán)限。
- Committer：具有將開發(fā)人員的合并請求MR合入主庫的權(quán)限。（ps：通?；诎踩紤]，我們設(shè)置為只能通過MR的方式將代碼合入主庫，而不能直接push到主庫）
- Developer：只能從自己的個人代碼庫提交合并代碼請求MR，是否能夠合入則由Committer進(jìn)行確認(rèn)。
Committer在進(jìn)行MR之前，可以對Developer提供的代碼進(jìn)行review
3、Git分支管理
master/main：與生產(chǎn)環(huán)境保持同步，該分支代碼都必須是穩(wěn)定的，禁止直接向該分支提交代碼。
develop ：持續(xù)開發(fā)的分支，每個開發(fā)人員都應(yīng)該在這個分支上保持線性的小步迭代。通常CodeReview 與開發(fā)級的自動CI也在該分支進(jìn)行。當(dāng)完成一個迭代(Sprint)的開發(fā)工作，并通過了自測、單元測試后，需要將該分支代碼合并到release分支，并要求打一個alpha級的Tag(如5.2.0-alpha)。
hotfix（
hotfix-前綴）： 如果軟件運(yùn)行過程中發(fā)現(xiàn)必須立即修改的bug，則從主庫的master/main分支中，拉出一個hotfix分支并指定bug修復(fù)版本。待hotfix分支的開發(fā)，驗(yàn)收工作完成后，需要以mr的方式合入master/main分支。并將該hotfix分支上的更新合并到dev分支（hotfix分支完成使命后，可以選擇刪除或保留）。release（
release-前綴）：顧名思義即用于發(fā)布過程的分支，包括集成測試，修復(fù)bug，回歸測試以及發(fā)布上線的過程。當(dāng)發(fā)布版本時要打一個發(fā)布beta級的Tag(如5.2.1-beta)，并將代碼合并到 master/main分支。在測試過程中發(fā)現(xiàn)的問題需要在release分支上進(jìn)行修改，并且將修改后的更新合并到dev分支。feature（
feat-）：添加一個新功能時，通常我們不希望因?yàn)橐恍?shí)驗(yàn)性質(zhì)的代碼將當(dāng)前的協(xié)同研發(fā)分支搞亂，因此每添加一個新功能時，可以在dev分支上拉取一個新的feature分支。當(dāng)新功能研發(fā)完畢后（完成了主體功能和大部分測試與bug修復(fù)工作），將該分支上的更新合并到dev分支上，并可選性的刪除該分支。
各個分支關(guān)系與運(yùn)行方式如下圖所示：
3.1 注意事項
- 通常我們團(tuán)隊習(xí)慣于將Tag打在release分支上的，master上不需要打Tag。當(dāng)然這不是必須準(zhǔn)尋的原則，可以根據(jù)實(shí)際情況自行選擇。
- develop分支上的內(nèi)容是通過release分支合并到master/main分支上的，要避免develop上的內(nèi)容直接合并到master/main分支。
4、Git fork過程
（1） 開發(fā)人員從主庫fork出自己的個人代碼庫。
（2） 開發(fā)人員將位于自己的個人代碼庫上fork的代碼clone到本地，即個人工作庫。
（3） 開發(fā)人員在完成代碼的調(diào)整后（包括新增，修改，刪除），先將代碼commit到個人工作庫，再由個人工作庫push到個人代碼庫。
（4） 開發(fā)人員提交從個人代碼庫到主庫的mr，Committer審核后，決定是否將mr合入主庫。
4.1 注意事項
- 使用Git fork管理項目時，原則上fork的項目只接受來自主庫上的更新合并請求，不接受將fork項目上的更新合并到主庫的過程。（社區(qū)開源項目的
pr方式則正好相反）
5. Git項目管理規(guī)范
Git使用的標(biāo)準(zhǔn)與否將直接影響到項目管理、CI/CD等工作的效率。一個較為完善的Git項目管理規(guī)范可參考下圖：
