目錄：

1. 規(guī)范的種類(lèi)
2. 倉(cāng)庫(kù)層級(jí)結(jié)構(gòu)規(guī)范
   1. 訪(fǎng)問(wèn)權(quán)限
3. 協(xié)作管理規(guī)范
4. 分支流轉(zhuǎn)規(guī)范
5. 分支命名規(guī)范
6. 合并規(guī)范
7. 合并請(qǐng)求規(guī)范
8. 標(biāo)簽命名規(guī)范
9. 提交規(guī)范

規(guī)范的種類(lèi)

在大多數(shù)人的腦海中 Git規(guī)范 = Git Flow 或者 Git規(guī)范 = Git Flow + 提交規(guī)范。
這大概是因?yàn)閺膩?lái)沒(méi)有人系統(tǒng)、深入地理解和總結(jié)過(guò) Git 規(guī)范相關(guān)的所有東西。

為了以后在 Git規(guī)范 方面有更清晰的表達(dá)，我這里對(duì) Git規(guī)范 相關(guān)的概念進(jìn)行重新定義下。

我把 Git 相關(guān)的規(guī)范分為了以下幾類(lèi)（可能還不全，日后會(huì)慢慢完善）：

• 倉(cāng)庫(kù)層級(jí)結(jié)構(gòu)規(guī)范：定義了倉(cāng)庫(kù)的分組（層級(jí)）結(jié)構(gòu)及訪(fǎng)問(wèn)權(quán)限。
• 協(xié)作管理規(guī)范：定義了多人協(xié)作時(shí)的管理策略。
• 分支流轉(zhuǎn)規(guī)范：定義了分支的來(lái)源、去向、合并、刪除等相關(guān)的規(guī)則。
• 合并規(guī)范：定義了合并操作的具體規(guī)則。
• 合并請(qǐng)求規(guī)范：定義了合并請(qǐng)求的步驟、信息等相關(guān)規(guī)則。
• 提交信息內(nèi)容規(guī)范（簡(jiǎn)稱(chēng)提交規(guī)范）：定義了提交文件的結(jié)構(gòu)、格式、信息類(lèi)型等規(guī)則。
• 分支命名規(guī)范：定義了分支名字結(jié)構(gòu)、格式等相關(guān)規(guī)則。
• 標(biāo)簽命名規(guī)范：定義了標(biāo)簽名字和信息結(jié)構(gòu)、格式、信息類(lèi)型等相關(guān)規(guī)則。

倉(cāng)庫(kù)層級(jí)結(jié)構(gòu)規(guī)范

詳情請(qǐng)看倉(cāng)庫(kù)層級(jí)結(jié)構(gòu)規(guī)范

倉(cāng)庫(kù)層級(jí)結(jié)構(gòu)圖

• 產(chǎn)品（組）：因?yàn)楫a(chǎn)品之間的關(guān)聯(lián)性較強(qiáng)，所以后端倉(cāng)庫(kù)不一定是按產(chǎn)品來(lái)劃分的，但前端大多數(shù)是按產(chǎn)品來(lái)劃分的，所以，針對(duì)產(chǎn)品，需要將 前端倉(cāng)庫(kù) 和 后端倉(cāng)庫(kù)分開(kāi)；
  • 后端（組）
    • 服務(wù)1（倉(cāng)庫(kù)）
    • 服務(wù)2（倉(cāng)庫(kù)）
  • 前端（組）
    • 產(chǎn)品1（倉(cāng)庫(kù)）
    • 產(chǎn)品2（倉(cāng)庫(kù)）
• 項(xiàng)目（組）：因?yàn)轫?xiàng)目之間的關(guān)聯(lián)性較弱，往往有各個(gè)的前端倉(cāng)庫(kù)和后端倉(cāng)庫(kù)，所以默認(rèn)情況可以將前端倉(cāng)庫(kù) 和 后端倉(cāng)庫(kù) 放在一起；如果某個(gè)項(xiàng)目只有前端倉(cāng)庫(kù)，沒(méi)有對(duì)應(yīng)的后端倉(cāng)庫(kù)，那就不必為項(xiàng)目創(chuàng)建組。
  • 項(xiàng)目1（組）
    • 前端（倉(cāng)庫(kù)）
    • 后端（倉(cāng)庫(kù)）
  • 項(xiàng)目2（倉(cāng)庫(kù)）：由于沒(méi)有后端，所以 項(xiàng)目2 直接作為前端倉(cāng)庫(kù)來(lái)創(chuàng)建，不必再創(chuàng)建成組
• 前端工具庫(kù)（組）：用于存放封裝的庫(kù)、工具等；因?yàn)檫@些工具大部分是通用的，服務(wù)于開(kāi)發(fā)人員的，所以本組的默認(rèn)訪(fǎng)問(wèn)權(quán)限可設(shè)為 內(nèi)部 internal，特殊的組或倉(cāng)庫(kù)除外；
  • 工具庫(kù)1（倉(cāng)庫(kù)）
  • 工具庫(kù)2（倉(cāng)庫(kù)）
• 后端工具庫(kù)（組）：用于存放封裝的庫(kù)、工具等；因?yàn)檫@些工具大部分是通用的，服務(wù)于開(kāi)發(fā)人員的，所以本組的默認(rèn)訪(fǎng)問(wèn)權(quán)限可設(shè)為 內(nèi)部 internal，特殊的組或倉(cāng)庫(kù)除外；
  • 工具庫(kù)1（倉(cāng)庫(kù)）
  • 工具庫(kù)2（倉(cāng)庫(kù)）
• 運(yùn)維（組）：存放一些基礎(chǔ)設(shè)施的項(xiàng)目，比如：監(jiān)控系統(tǒng)、日志系統(tǒng)、腳本架工具、運(yùn)維腳本等。
  • 工具1（組）
    • 前端（倉(cāng)庫(kù)）
    • 后端（倉(cāng)庫(kù)）
  • 工具2（倉(cāng)庫(kù)）：?jiǎn)为?dú)的工具，不分前后端，如：腳本等；

倉(cāng)庫(kù)目錄結(jié)構(gòu)圖

訪(fǎng)問(wèn)權(quán)限

一般情況，倉(cāng)庫(kù)或組的公開(kāi)性有以下幾種

• 私有 private：只有倉(cāng)庫(kù)或組的成員才可以訪(fǎng)問(wèn)；
• 內(nèi)部 internal：只有內(nèi)部用戶(hù)（登錄的用戶(hù)）才能訪(fǎng)問(wèn)；
• 公共 public：公開(kāi)的，所以有人員（登錄的 和 未登錄的）都可以訪(fǎng)問(wèn)；

• 所有的頂層組：均為內(nèi)部可見(jiàn)，這樣可以讓大家知道都有哪些分類(lèi)，以至于在創(chuàng)建項(xiàng)目或組時(shí)在地方可以創(chuàng)建；
• 對(duì)于頂層組內(nèi)部的組或倉(cāng)庫(kù)：
  • 工具庫(kù)內(nèi)部的組或倉(cāng)庫(kù)（內(nèi)部 internal）：包括前端工具庫(kù) 和 后端工具庫(kù)
    • 因?yàn)檫@些工具大部分是通用的，服務(wù)于開(kāi)發(fā)人員的，所以本組內(nèi)部的組或倉(cāng)庫(kù)的默認(rèn)訪(fǎng)問(wèn)權(quán)限可設(shè)為 內(nèi)部 internal，特殊的組或倉(cāng)庫(kù)除外；
    • 如果因些工具庫(kù)的源碼不方便暴露，但文檔需要大家都能訪(fǎng)問(wèn)，可將其文檔單獨(dú)存放在一個(gè)倉(cāng)庫(kù)中，分別為源碼 和 文檔設(shè)置不同的訪(fǎng)問(wèn)權(quán)限；
  • 產(chǎn)品、項(xiàng)目?jī)?nèi)部的組或倉(cāng)庫(kù) （私有 private）：由于 產(chǎn)品 和 項(xiàng)目 是公司重要資產(chǎn)，并且只需要相關(guān)人員對(duì)于源碼了解，所以這些組內(nèi)部的組或倉(cāng)庫(kù)的默認(rèn)訪(fǎng)問(wèn)權(quán)限應(yīng)設(shè)置為 私有 private；
  • 運(yùn)維內(nèi)部的組或倉(cāng)庫(kù)（私有 private）：運(yùn)維相關(guān)的工具通常只有運(yùn)維人員來(lái)維護(hù)，所以此組內(nèi)部的組或倉(cāng)庫(kù)的默認(rèn)訪(fǎng)問(wèn)權(quán)限應(yīng)設(shè)為 私有 private

一般情況下，倉(cāng)庫(kù)或組的成員角色有以下幾種：

• 管理員：擁有倉(cāng)庫(kù)完整的權(quán)限
• 開(kāi)發(fā)者：擁有提前、推送、拉取代碼的權(quán)限
• 瀏覽者：只能查看倉(cāng)庫(kù)，不能提交、推送倉(cāng)庫(kù)；

• 對(duì)于公司的職員：
  • 前端負(fù)責(zé)人擁有所有前端倉(cāng)庫(kù)的訪(fǎng)問(wèn)權(quán)限；
  • 后端負(fù)責(zé)人擁有所有后端倉(cāng)庫(kù)的訪(fǎng)問(wèn)權(quán)限；
  • 開(kāi)發(fā)人員只有其所負(fù)責(zé)項(xiàng)目的開(kāi)發(fā)者角色；
  • 項(xiàng)目負(fù)責(zé)人擁有其所負(fù)責(zé)項(xiàng)目的管理員角色；

協(xié)作管理規(guī)范

我在 Git協(xié)作管理方案 中介紹多種 Git協(xié)作管理方案，不同方案有不同的適用場(chǎng)景，具體使用哪種方案，因項(xiàng)目和團(tuán)隊(duì)結(jié)構(gòu)而定，但對(duì)于大多數(shù)小中型項(xiàng)目和團(tuán)隊(duì)而言，都比較適用下面2種方案：

• 開(kāi)測(cè)預(yù)發(fā)協(xié)作管理方案
• 穩(wěn)妥型開(kāi)測(cè)預(yù)發(fā)協(xié)作管理方案

如果這兩種方案不太理想，您可以在 Git協(xié)作管理方案 這篇文章中找到你想要的答案。

Git協(xié)作管理方案 這篇文章中講的比較抽象和通用，下面就針對(duì) 使用分支管理環(huán)境 且 支持合并請(qǐng)求 的項(xiàng)目倉(cāng)庫(kù) 來(lái)具化地描述下 開(kāi)測(cè)預(yù)發(fā)協(xié)作管理方案 和 穩(wěn)妥型開(kāi)測(cè)預(yù)發(fā)協(xié)作管理方案 的協(xié)作流程：

約定下各角色所管理的分支：

• 開(kāi)發(fā)組長(zhǎng)：開(kāi)發(fā)分支
• 測(cè)試者：測(cè)試分支
• 預(yù)發(fā)布者：預(yù)發(fā)布分支
• 發(fā)布者：發(fā)布分支

當(dāng)需要往這些分支上合并代碼時(shí)，都需要通過(guò) 合并請(qǐng)求 向?qū)?yīng)的分支負(fù)責(zé)人申請(qǐng)。

因?yàn)?穩(wěn)妥型開(kāi)測(cè)預(yù)發(fā)協(xié)作管理方案 只是在 開(kāi)測(cè)預(yù)發(fā)協(xié)作管理方案 的協(xié)作流程 上平加了 第6條，這是為了確保 開(kāi)發(fā)分支 上包含了 發(fā)布分支 的全部代碼，所以可以將 開(kāi)測(cè)預(yù)發(fā)協(xié)作管理方案 和 穩(wěn)妥型開(kāi)測(cè)預(yù)發(fā)協(xié)作管理方案 的協(xié)作流程統(tǒng)一描述，如下：

協(xié)作流程：

1. 開(kāi)發(fā)者基于 開(kāi)發(fā)分支 創(chuàng)建 功能分支；
2. 向開(kāi)發(fā)組長(zhǎng)發(fā)起 合并請(qǐng)求，并在標(biāo)題上添加前綴 WIP 標(biāo)識(shí)；
3. 開(kāi)發(fā)者在 功能分支 上做開(kāi)發(fā)；
4. 開(kāi)發(fā)組長(zhǎng)審查代碼，對(duì)有問(wèn)題的地方進(jìn)行批注，并要求開(kāi)發(fā)者改正；
5. 當(dāng)開(kāi)發(fā)完畢后，相關(guān)人員在 功能分支 上進(jìn)行驗(yàn)收；
6. 驗(yàn)收通過(guò)后，把 開(kāi)發(fā)分支 上最新的變更合并進(jìn)來(lái)；
7. 開(kāi)發(fā)者自測(cè)；
8. 自測(cè)試沒(méi)問(wèn)題后，去除合并請(qǐng)求的WIP前綴，并通知開(kāi)發(fā)組長(zhǎng)處理請(qǐng)求；
9. ??（穩(wěn)妥型方案特有的步驟）開(kāi)發(fā)組長(zhǎng)將 發(fā)布分支 上的新變更 合并到 開(kāi)發(fā)分支上。
10. 開(kāi)發(fā)組長(zhǎng)確定沒(méi)問(wèn)題后，同意 合并請(qǐng)求，并執(zhí)行合并操作；
11. 開(kāi)發(fā)組長(zhǎng)向測(cè)試者發(fā)起 合并請(qǐng)求；
12. 測(cè)試者同意請(qǐng)求并執(zhí)行合并操作；
13. 測(cè)試者進(jìn)行測(cè)試；
14. 測(cè)試者測(cè)試通過(guò)后，向 預(yù)發(fā)布者 發(fā)起 合并請(qǐng)求；
15. 預(yù)發(fā)布者接受請(qǐng)求并執(zhí)行合并操作；
16. 預(yù)發(fā)布者在預(yù)發(fā)布環(huán)境測(cè)試；
17. 預(yù)發(fā)布環(huán)境測(cè)試通過(guò)后，預(yù)發(fā)布者向 發(fā)布者 發(fā)起 合并請(qǐng)求；
18. 發(fā)布者接受請(qǐng)求并執(zhí)行合并操作；

開(kāi)測(cè)預(yù)發(fā)協(xié)作步驟-簡(jiǎn)化版

分支流轉(zhuǎn)規(guī)范

目前有以下幾種分支流轉(zhuǎn)規(guī)范（關(guān)于前三者之間的區(qū)別，可看 Git 工作流程 這篇文章）：

• Git Flow：適合基于 版本發(fā)布 的項(xiàng)目，即：需要一段時(shí)間以后才會(huì)產(chǎn)出一個(gè)新版本的項(xiàng)目。
• GitHub Flow：適合 持續(xù)發(fā)布 的項(xiàng)目。
• GitLab Flow：持續(xù)發(fā)布 和 版本發(fā)布 的項(xiàng)目都適合，且支持多種環(huán)境。
• Git并行工作流程規(guī)范: 適合經(jīng)常有很多并行功能開(kāi)發(fā)的項(xiàng)目。

個(gè)人比較推薦 GitLab Flow 和 Git并行工作流程規(guī)范。

分支命名規(guī)范

• 使用 / 作為分隔符來(lái)表達(dá)層次關(guān)系；如 模塊/功能。
  • 相比 中劃線(xiàn) -、下劃線(xiàn) _ 等其它的分隔符來(lái)說(shuō)，/ 具有如下優(yōu)勢(shì)：
    • 與路徑分隔符一致，從形式上更能表達(dá)出層級(jí)結(jié)構(gòu)。
    • 很多 git 工具會(huì)將 / 解析分隔符并將分支名作為路徑來(lái)解析，然后以文件樹(shù)的形式展示分支，這樣可以更好的組織分支。
• 名稱(chēng)中應(yīng)避免冗余信息；如 模塊A/模塊A_功能A 中的 模塊A_功能A 中的 模塊A 就是冗余信息。

合并規(guī)范

• 開(kāi)發(fā)分支只能合并當(dāng)前迭代版本的功能；

合并請(qǐng)求規(guī)范

• 對(duì)于需要代碼審查的分支，如果其直接下游分支是明確的，則該分支到直接下游分支的合并請(qǐng)求可以提前創(chuàng)建（比如在創(chuàng)建該分支時(shí)就創(chuàng)建到直接下游分支的合并請(qǐng)求），但此時(shí)合并請(qǐng)求的標(biāo)題上應(yīng)加上前綴 WIP （Work in progress 之意）標(biāo)識(shí)，來(lái)表示該分支仍在開(kāi)發(fā)中，當(dāng)前狀態(tài)不可合并；在真正開(kāi)完成時(shí)，再移除前綴 WIP 標(biāo)識(shí)，以表示當(dāng)前分支處于可合并的狀態(tài)；這樣設(shè)計(jì)的目的是：
  • 可讓合并請(qǐng)求的處理人員提前知道將來(lái)都有哪些分支需要合并；
  • 合并請(qǐng)求的相關(guān)處理人員也可以提前做一些工作，比如：代碼審查 等，而不用等到開(kāi)完成時(shí)統(tǒng)一檢查；在開(kāi)發(fā)完成時(shí)再審查，往往審查的代碼量太多，導(dǎo)致審查不完成 或 不仔細(xì)；
  • 分支開(kāi)發(fā)人員 和 合并請(qǐng)求處理人員可以在分支的開(kāi)發(fā)期間連續(xù)互動(dòng)（通過(guò)評(píng)審、審查等），以便及時(shí)發(fā)現(xiàn)問(wèn)題、改正問(wèn)題；
• 向 測(cè)試分支、預(yù)發(fā)布分支、發(fā)布分支 發(fā)起的合并請(qǐng)求中一定要指定 里程碑 和 標(biāo)簽；
• 對(duì)于修復(fù)分支，一定要等到修復(fù)分支到母分支的合并請(qǐng)求合并完成之后，再繼續(xù)執(zhí)行合并到開(kāi)發(fā)分支的后續(xù)操作，否則容易造成將開(kāi)發(fā)分支上的代碼合并到修復(fù)分支的母分支上；
• 合并請(qǐng)求合并完成后，要及時(shí)刪除源分支；

標(biāo)簽命名規(guī)范

采用 語(yǔ)義化版本 規(guī)范來(lái)命名標(biāo)簽。標(biāo)簽的格式為：

<主版本號(hào)>.<次版本號(hào)>.<修訂號(hào)>[.<測(cè)試版本號(hào)>]

• 主版本號(hào)：當(dāng)你做了不兼容的 API 修改，
• 次版本號(hào)：當(dāng)你做了向下兼容的功能性新增，
• 修訂號(hào)：當(dāng)你做了向下兼容的問(wèn)題修正。
• 測(cè)試版本號(hào)： 當(dāng)需要標(biāo)明測(cè)試版本時(shí)可以在后面追加測(cè)試版本號(hào)，測(cè)試版本號(hào)可以使用測(cè)試輪數(shù)來(lái)指代。
• 先行版本號(hào)及版本編譯信息可以加到 <主版本號(hào)>.<次版本號(hào)>.<修訂號(hào)> 的后面，作為延伸。

提交規(guī)范

詳見(jiàn) 提交規(guī)范