您必須知道的 Git 分支開發規範

時間 2019-12-14

標籤必須知道 git 分支開發規範欄目 Git 简体版

原文原文鏈接

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

分支管理

分支命名

master 分支git

master 爲主分支，也是用於部署生產環境的分支，確保master分支穩定性
master 分支通常由develop以及hotfix分支合併，任什麼時候間都不能直接修改代碼

develop 分支github

develop 爲開發分支，始終保持最新完成以及bug修復後的代碼
通常開發的新功能時，feature分支都是基於develop分支下建立的

feature 分支web

開發新功能時，以develop爲基礎建立feature分支
分支命名: feature/ 開頭的爲特性分支，命名規則: feature/user_module、 feature/cart_module

release分支segmentfault

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

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

hotfix 分支bash

分支命名: hotfix/ 開頭的爲修復分支，它的命名規則與 feature 分支相似
線上出現緊急問題時，須要及時修復，以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

修復緊急bugide

(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，而後在測試環境拉取並測試

生產環境上線post

(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

具體格式爲:

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

type: 本次 commit 的類型，諸如 bugfix docs style 等
scope: 本次 commit 波及的範圍
subject: 簡明扼要的闡述下本次 commit 的主旨，在原文中特地強調了幾點 1. 使用祈使句，是否是很熟悉又陌生的一個詞，來傳送門在此祈使句 2. 首字母不要大寫 3. 結尾無需添加標點
body: 一樣使用祈使句，在主體內容中咱們須要把本次 commit 詳細的描述一下，好比這次變動的動機，如需換行，則使用 |
footer: 描述下與之關聯的 issue 或 break change，詳見案例

Type的類別說明：

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

Commit messages格式要求

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