一、背景問題

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

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

二、方案

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

2.1、人員角色

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

1、項目組長 - Team Leader

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

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

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

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

2.2、角色分工

根據(jù)人員分工，劃分每個角色可操作的環(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分支合并，任何時間都不能直接修改代碼

2、develop 分支

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

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

3、feature 分支

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

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

4、release分支

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

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

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

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

5、hotfix 分支

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

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

2.3.2、分支流程管理

git flow 流程圖參考以下

git flow流程圖參考

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

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

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

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

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

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

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

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

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

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

Commit Masseage 的格式規(guī)范

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

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

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

1. feat：新功能（feature）

2. fix：修補 bug

3. docs：文檔（documentation）

4. style：格式（不影響代碼運行的變動）

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

6. test：增加測試

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

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

• subject 是 commit 目的的簡短描述，不超過 50 個字符。

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

Footer 部分只用于兩種情況。

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

• 關(guān)閉 Issue，如果當(dāng)前 commit 針對某個 issue，那么可以在 Footer 部分關(guān)閉這個 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、測試環(huán)境代碼

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

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

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

3.1.5、 代碼合并

代碼合并是個技術(shù)活，這里提2個點

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

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

以下基于Idea git插件方式進行代碼合并說明：

3.1.5.1、建立分支

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

操作如下

1、idea git分支的操作

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

說明：

• 【new branch】新建分支

• 【local branches】本地分支

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

• 【remote branches】遠程倉庫分支。我在這里配置了兩個遠程倉庫，所以這里顯示2個。

2、創(chuàng)建分支

點擊【new branch】，彈出窗口，如下圖：

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

3、切換分支

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

點擊【checkout】

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

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

5、提交分支到本地庫

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

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

彈出新窗口，如下圖：

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

commit表示提交代碼到本地庫

彈出警告窗口如下圖：

點擊【commit and push】，提交本地庫成功！

3.1.5.2、合并到master主分支

1）、切換到master主分支

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

操作如下圖：

點擊merge

注意：

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

• 然后在要合并的分支上點擊merge

3）、推送到遠程倉庫

操作如下圖：

點擊【push】

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

?

四、小結(jié)

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

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

閱讀原文：原文鏈接