我司後端必備 Git 分支開發：規範指南

時間 2020-12-18

標籤 git github app 運維 ide 工具性能測試 url 欄目 Git 简体版

原文原文鏈接

Git 是目前最流行的源代碼管理工具。爲規範開發，保持代碼提交記錄以及 git 分支結構清晰，方便後續維護，現規範 git 的相關操做。git

分支命名

master 分支

master 爲主分支，也是用於部署生產環境的分支，確保master分支穩定性github

master 分支通常由develop以及hotfix分支合併，任什麼時候間都不能直接修改代碼app

develop 分支

develop 爲開發分支，始終保持最新完成以及bug修復後的代碼運維

通常開發的新功能時，feature分支都是基於develop分支下建立的ide

feature 分支

開發新功能時，以develop爲基礎建立feature分支工具

分支命名: feature/ 開頭的爲特性分支，命名規則: feature/user_module、 feature/cart_module性能

release分支

release 爲預上線分支，發佈提測階段，會release分支代碼爲基準提測測試

「當有一組feature開發完成，首先會合併到develop分支，進入提測時，會建立release分支。若是測試過程當中若存在bug須要修復，則直接由開發者在release分支修復並提交。當測試完成以後，合併release分支到master和develop分支，此時master爲最新代碼，用做上線。ui

hotfix 分支

分支命名: hotfix/ 開頭的爲修復分支，它的命名規則與 feature 分支相似url

線上出現緊急問題時，須要及時修復，以master分支爲基線，建立hotfix分支，修復完成後，須要合併到master分支和develop分支

常見任務

增長新功能

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

修復緊急bug

(master)$: git checkout -b hotfix/xxx         # 從master創建hotfix分支
(hotfix/xxx)$: blabla                         # 開發
(hotfix/xxx)$: git add xxx
(hotfix/xxx)$: git commit -m 'commit comment'
(master)$: git merge hotfix/xxx --no-ff       # 把hotfix分支合併到master，並上線到生產環境
(dev)$: git merge hotfix/xxx --no-ff          # 把hotfix分支合併到dev，同步代碼

測試環境代碼

(release)$: git merge dev --no-ff             # 把dev分支合併到release，而後在測試環境拉取並測試

生產環境上線

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

日誌規範

在一個團隊協做的項目中，開發人員須要常常提交一些代碼去修復bug或者實現新的feature。

而項目中的文件和實現什麼功能、解決什麼問題都會漸漸淡忘，最後須要浪費時間去閱讀代碼。可是好的日誌規範commit messages編寫有幫助到咱們，它也反映了一個開發人員是不是良好的協做者。

編寫良好的Commit messages能夠達到3個重要的目的：

加快review的流程
幫助咱們編寫良好的版本發佈日誌
讓以後的維護者瞭解代碼裏出現特定變化和feature被添加的緣由

目前，社區有多種 Commit message 的寫法規範。來自Angular 規範是目前使用最廣的寫法，比較合理和系統化。以下圖：

Commit messages的基本語法

當前業界應用的比較普遍的是 Angular Git Commit Guidelines

「

https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines

具體格式爲:

<type>: <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

type: 本次 commit 的類型，諸如 bugfix docs style 等

scope: 本次 commit 波及的範圍

subject: 簡明扼要的闡述下本次 commit 的主旨，在原文中特地強調了幾點：

使用祈使句，是否是很熟悉又陌生的一個詞
首字母不要大寫
結尾無需添加標點

body: 一樣使用祈使句，在主體內容中咱們須要把本次 commit 詳細的描述一下，好比這次變動的動機，如需換行，則使用 |

footer: 描述下與之關聯的 issue 或 break change

Type的類別說明：

feat: 添加新特性
fix: 修復bug
docs: 僅僅修改了文檔
style: 僅僅修改了空格、格式縮進、都好等等，不改變代碼邏輯
refactor: 代碼重構，沒有加新功能或者修復bug
perf: 增長代碼進行性能測試
test: 增長測試用例
chore: 改變構建流程、或者增長依賴庫、工具等

Commit messages格式要求

# 標題行：50個字符之內，描述主要變動內容
#
# 主體內容：更詳細的說明文本，建議72個字符之內。 須要描述的信息包括:
#
# * 爲何這個變動是必須的? 它多是用來修復一個bug，增長一個feature，提高性能、可靠性、穩定性等等
# * 他如何解決這個問題? 具體描述解決問題的步驟
# * 是否存在反作用、風險?
#
# 若是須要的化能夠添加一個連接到issue地址或者其它文檔