一、背景問題

Git作為一款優(yōu)秀的分布式代碼管理工具，在開發(fā)過程中為團(tuán)隊(duì)提供了極大的便利。然而，正如俗話所說，“無規(guī)矩不成方圓”。如果沒有合理的分支管理規(guī)范，可能會(huì)引發(fā)一系列問題，比如：

1、代碼沖突：開發(fā)者直接從 master 分支拉取代碼進(jìn)行修改，合并時(shí)出現(xiàn)各種沖突，解決起來困難重重，往往會(huì)影響開發(fā)進(jìn)度。

二、方案

以上的種種問題的根源在于 Git 分支管理的缺失規(guī)范。通過合理的管理規(guī)范，可以有效減少生產(chǎn)事故并提高研發(fā)效率。

2.1、人員角色

首先，根據(jù)研發(fā)人員的職責(zé)，我們可以將角色劃分為：

1、項(xiàng)目組長(zhǎng) - Team Leader

2、需求開發(fā)研發(fā) - Developer

3、系統(tǒng)集成測(cè)試人員 - SIT Tester

4、系統(tǒng)用戶故事測(cè)試人員 - UAT Tester

5、系統(tǒng)運(yùn)維人員 - Operator

2.2、角色分工

根據(jù)人員分工，劃分每個(gè)角色可操作的環(huán)境權(quán)限。具體劃分如下：

2.3、分支管理

2.3.1、分支命名規(guī)范

根據(jù)角色和權(quán)限管理，創(chuàng)建不同的分支。以下是各類分支的命名規(guī)范及示例：

1、master 分支

• master 為主分支，也是用于部署生產(chǎn)環(huán)境的分支，確保master分支穩(wěn)定性

• master 分支一般由develop以及hotfix分支合并，任何時(shí)間都不能直接修改代碼

2、develop 分支

• develop 為開發(fā)分支，始終保持最新完成以及bug修復(fù)后的代碼

• 一般開發(fā)的新功能時(shí)，feature分支都是基于develop分支下創(chuàng)建的

3、feature 分支

• 開發(fā)新功能時(shí)，以develop為基礎(chǔ)創(chuàng)建feature分支

• 分支命名: feature/ 開頭的為特性分支， 命名規(guī)則: feature/user_module、 feature/cart_module

4、release分支

• release 為預(yù)上線分支，發(fā)布提測(cè)階段，會(huì)release分支代碼為基準(zhǔn)提測(cè)

當(dāng)有一組feature開發(fā)完成，首先會(huì)合并到develop分支，進(jìn)入提測(cè)時(shí)，會(huì)創(chuàng)建release分支。

如果測(cè)試過程中若存在bug需要修復(fù)，則直接由開發(fā)者在release分支修復(fù)并提交。

當(dāng)測(cè)試完成之后，合并release分支到master和develop分支，此時(shí)master為最新代碼，用作上線。

5、hotfix 分支

• 分支命名: hotfix/ 開頭的為修復(fù)分支，它的命名規(guī)則與 feature 分支類似

• 線上出現(xiàn)緊急問題時(shí)，需要及時(shí)修復(fù)，以master分支為基線，創(chuàng)建hotfix分支，修復(fù)完成后，需要合并到master分支和develop分支。

2.3.2、分支流程管理

git flow 流程圖參考以下

git flow流程圖參考

1、一個(gè)新的項(xiàng)目需求立項(xiàng)后，初始化項(xiàng)目分支，默認(rèn)創(chuàng)建 master 分支，然后從 master 分支 checkout -b Develop 分支。

2、每位開發(fā)人員認(rèn)領(lǐng)自己的功能需求，分別從 Develop 分支拉取自己個(gè)人分支進(jìn)行功能編碼。敏捷開發(fā)強(qiáng)調(diào)功能小版本迭代，并行開發(fā)。

3、當(dāng)研發(fā)人員每個(gè) feature 分支完成，開發(fā)自測(cè)之后，提交 merge request，team leader 經(jīng)過 code review 確定運(yùn)行無缺陷后合并到 develop 分支。

4、此時(shí) sit 測(cè)試人員需要從 develop 分支打包最新代碼，并部署 sit 測(cè)試環(huán)境，同步進(jìn)行功能及接口測(cè)試，強(qiáng)調(diào)敏捷中的 “測(cè)試驅(qū)動(dòng)原則”。

5、當(dāng)所有 feature 都已合并并且 sit tester 打包測(cè)試無誤后，從此時(shí)的 develop 分支拉取最新代碼同步到 release 分支，并打包代碼部署到 UAT 預(yù)生產(chǎn)環(huán)境進(jìn)行 uat 測(cè)試，測(cè)試過程中的缺陷直接在 release 分支進(jìn)行修復(fù)，研發(fā)及測(cè)試人員對(duì)修復(fù)的代碼進(jìn)行缺陷回歸。

6、release 分支代碼回歸測(cè)試，無誤后發(fā)布上線，同時(shí)合并到 master 分支。

此時(shí)，一個(gè)項(xiàng)目從最初的開發(fā)編碼到發(fā)版上線，整個(gè)研發(fā)流程確保清晰明了。保證整個(gè)研發(fā)流程規(guī)范，可以大大減少生產(chǎn)事故。當(dāng)然，不可避免的也會(huì)有生產(chǎn)問題，如果此時(shí)出現(xiàn)生產(chǎn)問題，需要直接從 master 分支同步代碼至 hotfix 分支，修復(fù)生產(chǎn)問題并復(fù)測(cè)回歸。這種流程下，比較容易出現(xiàn)沖突的場(chǎng)景及解決方案如下：

1）、多 feature 分支并行開發(fā)，在提交測(cè)試合并至 develop 分支時(shí)，容易出現(xiàn)合并沖突。這就要求各研發(fā)人員盡量只修改個(gè)人功能代碼文件。公共配置或公共依賴包應(yīng)由單獨(dú)開發(fā)人員維護(hù)，按需添加，修改合并后推送到各 feature 分支。

2）、Hotfix 分支修復(fù)的同時(shí)有 release 分支功能需要發(fā)版上線，合并 master 時(shí)容易出現(xiàn)合并沖突。這時(shí)按功能生產(chǎn)環(huán)境緊急性依次發(fā)布上線，發(fā)版上線后立即合并 master 并推送到另一分支 (hotfix/release)。

2.3.3、提交日志規(guī)范

Commit Masseage 的格式規(guī)范

每次提交，Commit message 都包括三個(gè)部分：Header，Body 和 Footer。其中，Header 是必需的，Body 和 Footer 可以省略。

Header 部分只有一行，包括三個(gè)字段：type（必需）、scope（可選）和 subject（必需）。

• type，type 用于說明 commit 的類別，只允許使用下面 7 個(gè)標(biāo)識(shí)。

1. feat：新功能（feature）

2. fix：修補(bǔ) bug

3. docs：文檔（documentation）

4. style：格式（不影響代碼運(yùn)行的變動(dòng)）

5. refactor：重構(gòu)（即不是新增功能，也不是修改 bug 的代碼變動(dòng)）

6. test：增加測(cè)試

7. chore：構(gòu)建過程或輔助工具的變動(dòng)

• scope，scope 用于說明 commit 影響的范圍，比如數(shù)據(jù)層、控制層、視圖層等等，視項(xiàng)目不同而不同。

• subject 是 commit 目的的簡(jiǎn)短描述，不超過 50 個(gè)字符。

Body 部分是對(duì)本次 commit 的詳細(xì)描述，可以分成多行。

Footer 部分只用于兩種情況。

• 不兼容變動(dòng)，如果當(dāng)前代碼與上一個(gè)版本不兼容，則 Footer 部分以 BREAKING CHANGE 開頭，后面是對(duì)變動(dòng)的描述、以及變動(dòng)理由和遷移方法。

• 關(guān)閉 Issue，如果當(dāng)前 commit 針對(duì)某個(gè) issue，那么可以在 Footer 部分關(guān)閉這個(gè) issue

三、操作方法

3.1、常見任務(wù)命令行操作

3.1.1、增加新功能

(dev)$: git checkout -b feature/xxx  # 從dev建立特性分支(feature/xxx)$: blabla  #開發(fā)(feature/xxx)$: git add xxx(feature/xxx)$: git commit -m 'commit comment'(dev)$: git merge feature/xxx --no-ff          # 把特性分支合并到dev

3.1.2、修復(fù)緊急bug

(master)$: git checkout -b hotfix/xxx         # 從master建立hotfix分支(hotfix/xxx)$: blabla                         # 開發(fā)(hotfix/xxx)$: git add xxx(hotfix/xxx)$: git commit -m 'commit comment'(master)$: git merge hotfix/xxx --no-ff       # 把hotfix分支合并到master，并上線到生產(chǎn)環(huán)境(dev)$: git merge hotfix/xxx --no-ff          # 把hotfix分支合并到dev，同步代碼

3.1.3、測(cè)試環(huán)境代碼

(release)$: git merge dev --no-ff             # 把dev分支合并到release，然后在測(cè)試環(huán)境拉取并測(cè)試

3.1.4、生產(chǎn)環(huán)境上線

(master)$: git merge release --no-ff        # 把release測(cè)試好的代碼合并到master，運(yùn)維人員操作(master)$: git tag -a v0.1 -m '部署包版本名'  #給版本命名，打Tag

3.1.5、 代碼合并

代碼合并是個(gè)技術(shù)活，這里提2個(gè)點(diǎn)

第一點(diǎn)是合并注意事項(xiàng)：1）、由開發(fā)人員發(fā)起合并，對(duì)于沖突比較多的，可以2個(gè)人以上進(jìn)行合并；2）、系統(tǒng)參與者 評(píng)審人員 review通過后，才正式合并到分支。

第二點(diǎn)是合并方式：可基于命令行也可基于Idea git插件代碼建立分支與合并分支。

以下基于Idea git插件方式進(jìn)行代碼合并說明：

3.1.5.1、建立分支

git默認(rèn)的主分支名字為master，一般團(tuán)隊(duì)開發(fā)時(shí)，都不會(huì)在master主分支上修改代碼，而是建立新分支，測(cè)試完畢后，在將分支的代碼合并到master主分支上。

操作如下

1、idea git分支的操作

idea git的操作在右下角，如下圖：

說明：

• 【new branch】新建分支

• 【local branches】本地分支

• 【current master】表示當(dāng)前是主分支

• 【remote branches】遠(yuǎn)程倉庫分支。我在這里配置了兩個(gè)遠(yuǎn)程倉庫，所以這里顯示2個(gè)。

2、創(chuàng)建分支

點(diǎn)擊【new branch】，彈出窗口，如下圖：

輸入分支名稱點(diǎn)【OK】，然后默認(rèn)切換到該分支。

3、切換分支

如果要切換回master主分支，操作如下圖：

點(diǎn)擊【checkout】

4、在新建立的分支上修改代碼

切換到之前新創(chuàng)建的分支，修改代碼。

5、提交分支到本地庫

一般情況下只需要將分支提交到本地倉庫，不需要將分支提交遠(yuǎn)程倉庫。如果將所有的分支都提交到遠(yuǎn)程倉庫，會(huì)讓遠(yuǎn)程倉庫雜亂無章。

確保在新建分支下，操作如下圖：

彈出新窗口，如下圖：

選擇要提交的文件，寫上提交注釋，然后點(diǎn)擊【commit】

commit表示提交代碼到本地庫

彈出警告窗口如下圖：

點(diǎn)擊【commit and push】，提交本地庫成功！

3.1.5.2、合并到master主分支

1）、切換到master主分支

2）、合并代碼到master主分支

操作如下圖：

點(diǎn)擊merge

注意：

• 當(dāng)前必須切換到master主分支

• 然后在要合并的分支上點(diǎn)擊merge

3）、推送到遠(yuǎn)程倉庫

操作如下圖：

點(diǎn)擊【push】

提交成功后右下角彈出信息：

?

四、小結(jié)

1、分支管理的重要性：良好的管理規(guī)范能適當(dāng)減少生產(chǎn)事故，提高研發(fā)效率。

2、對(duì)于分支如何管理：文中就分支流程管理和常見操作進(jìn)行了說明，希望能夠幫到大家。

閱讀原文：原文鏈接