後端必備的 Git 分支開發規範指南轉

時間 2020-04-23

標籤後端必備 git 分支開發規範指南欄目 Git 简体版

原文原文鏈接

原文連接做者：稻草叔叔 http://juejin.im/post/5b4328bbf265da0fa21a6820html

點擊上方「後端技術精選」，選擇「置頂公衆號」git

技術文章第一時間送達！github

做者：稻草叔叔web

juejin.im/post/5b4328bbf265da0fa21a6820面試

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

分支管理

分支命名

master 分支

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

develop 分支

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

feature 分支

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

release 分支

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

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

hotfix 分支

分支命名: 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

修復緊急 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 的主旨，在原文中特地強調了幾點 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地址或者其它文檔