Git 工做流，看這一篇就夠了

時間 2021-08-13

標籤前端 webpack git github web npm json 前端框架微信框架欄目 Git 简体版

原文原文鏈接

1. Git 提交規範

做爲一個開發人員必不可少的工具，代碼提交平常一個很是頻繁的操做，而對於團隊規範建設來講，Git提交信息的規範是一件頗有必要的工做。前端

1.1 爲何要規範提交信息

首先規範提交信息確定是有必要的，簡單總結下幾點好處：webpack

讓項目的維護或使用人員能瞭解提交了哪些更改
清晰的歷史記錄，可能某天本身就須要查到呢
規範的提交記錄可用於自動生成修改日誌(CHANGELOG.MD)
基於提交類型，觸發構建和部署流程

1.2 用什麼規範？

如今市面上比較流行的方案是約定式提交規範（Conventional Commits），它受到了 Angular 提交準則的啓發，並在很大程度上以其爲依據。約定式提交規範是一種基於提交消息的輕量級約定。它提供了一組用於建立清晰的提交歷史的簡單規則；這使得編寫基於規範的自動化工具變得更容易。這個約定與 SemVer 相吻合，在提交信息中描述新特性、bug 修復和破壞性變動。它的 message 格式以下:git

對於提交的備註至少包含四種前綴描述，方便相互瞭解變更了啥github

<類型>[可選的做用域]: <描述> [可選的正文] [可選的腳註]複製代碼

1.3 Commit message 規範落地

目前，社區有多種 Commit message 的寫法規範。參考Angular 規範是目前使用最廣的寫法，比較合理和系統化，而且有配套的工具。前端框架Angular.js採用的就是該規範。以下圖：下面是一個規範信息的結構web

<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>複製代碼

每一個 Git 的 Commit Messages 由如下三部分組成， **header(標題) ** , 可選的 ** body(正文) ** ，可選的 ** footer(頁腳)，break changes(刪減) ** 其中header是必填項。`npm

一、type

type 爲必填項，用於指定 commit 的類型，約定了 feat、fix 兩個主要 type，以及 docs、style、build、refactor、revert 五個特殊 type，其他 type 暫不使用。json

主要 type前端框架

feat：增長功能
fix：修復 bug

特殊 type微信

docs：文檔變更（documentation）
style：格式變更（不影響代碼運行的變更）
revert: 執行 git revert 打印的 message
build：構造工具的或者外部依賴的改動，例如 webpack，npm
refactor：重構代碼（即不是新增功能，也不是修改 bug 的代碼變更）

暫不使用 type框架

merge：解決衝突時合併提交，並未作代碼變更
chore：輔助工具的變更, 或者其餘變更等
test: 添加測試或者修改現有測試
perf: 提升性能的改動
ci: 與 CI（持續集成服務）有關的改動

當一次改動包括主要 type 與特殊 type 時，統一採用主要 type。

若是 type 爲feat和fix，則該 commit 將確定出如今 Change log 之中。其餘狀況（docs、chore、style、refactor、test）由你決定，要不要放入 Change log，建議是不要。

二、scope

scope 也爲必填項，簡單說明，不超過50個字, 中英文都可，若爲英文須首字母大寫，用於描述改動的範圍，格式爲項目名/模塊名，例如：opinions/topic。若是一次 commit 修改多個模塊，建議拆分紅屢次 commit，以便更好追蹤和維護。

三、body

body 填寫詳細描述，主要描述改動以前的狀況及修改動機，對於小的修改不做要求，可是重大需求、更新等必須添加 body 來做說明。

四、footer

可選。主要用於備註相關 bug 的 id，如用 gitlab 須備註 issue 連接 Example Commit Message

5 、break changes

break changes 指明是否產生了破壞性修改，涉及 break changes 的改動必須指明該項，相似版本升級、接口參數減小、接口刪除、遷移等。

示例

feat(訂單流程): 開發支付頁
feat(訂單流程): 聯調支付功能複製代碼

每次提交都應該是原子性的，要麼是修復bug，要麼是新功能，要麼是文檔修改等等，絕對不容許多個type類型提交混合一塊兒，否則難以 code review。

更詳細的說明請看約定式提交規範

1.4 Quick Start

如何約束規範，安裝 commitlint 和 commitizen 規範和編寫符合規範的 commit message

一、全局安裝 commitizen & cz-conventional-changelog

commitizen 是一個撰寫合格 commit message 的工具，用於代替 git commit 指令，而 cz-conventional-changelog 適配器提供 conventional-changelog 標準（約定式提交標準）。基於不一樣需求，也可使用不一樣適配器。

npm install -g commitizen cz-conventional-changelogecho '{ "path": "cz-conventional-changelog" }' > ~/.czrc複製代碼

安裝完畢後，可直接使用 git cz 來取代 git commit。

全局模式下，須要 ~/.czrc 配置文件, 爲 commitizen 指定 Adapter。

二、項目內安裝 commitlint & husky

commitlint 負責用於對 commit message 進行格式校驗，husky 負責提供更易用的 git hook。

# Use npmnpm i -D husky @commitlint/config-conventional @commitlint/cli# Use yarnyarn add husky @commitlint/config-conventional @commitlint/cli -D複製代碼

commitlint 只能作格式規範，沒法觸及內容。對於內容質量的把控只能靠咱們本身。

三、添加相應配置

建立 commitlint.config.js

# In the same path as package.jsonecho 'module.exports = {extends: ["@commitlint/config-conventional"]};' > ./commitlint.config.js複製代碼

引入 husky

# package.json
{
...,"husky": {"hooks": {"commit-msg": "commitlint -e $GIT_PARAMS"}
}複製代碼

四、使用

執行 git cz 進入 interactive 模式，根據提示依次填寫

1.Select the type of change that you're committing 選擇改動類型 (<type>)

2.What is the scope of this change (e.g. component or file name)? 填寫改動範圍 (<scope>)

3.Write a short, imperative tense description of the change: 寫一個精簡的描述 (<subject>)

4.Provide a longer description of the change: (press enter to skip) 對於改動寫一段長描述 (<body>)

5.Are there any breaking changes? (y/n) 是破壞性修改嗎？默認n (<footer>)

6.Does this change affect any openreve issues? (y/n) 改動修復了哪一個問題？默認n (<footer>)複製代碼

生成的 commit message 格式以下：

<type
  >(<scope>):<subject>  <BLANK LINE><body>  <BLANK LINE> <footer></footer></BLANK></body></BLANK></subject></scope
></type>複製代碼

填寫完畢後，husky 會調用 commitlint 對 message 進行格式校驗，默認規定 type 及 subject 爲必填項。

任何 git commit 指令的 option 都能用在 git cz 指令上, 例如 git cz -a

2. Git 分支管理

Git分支管理及命名規範

2.1 分支分類

Git主分支（保留分支）：master 、release

Git開發分支（合併至master分支）：dev、dev/[function-username]

Git輔助分支（功能/輔助分支）：feature/[function]、hotfix/、release/

2.2 分支簡介

2.2.1 主分支

master：對應線上（正式環境）的代碼，一旦版本上線由測試人員發送合併matser郵件，開發人員將對應上線tag版本合併至master分支。
release：同 master 分支，預發環境經過以後，上線以前，合併 release 分支。

2.2.2 dev、dev/[function-username] 開發分支

dev：平常功能迭代開發使用的爲 dev 分支，最初是從 master 拉出，後面全部的功能開發都 merge 回此分支協同開發。
dev/[function-username]：開發者本身的功能分支，根據功能模塊-企業微信名稱來命名，完成後 merge 回 feature/[function] 分支，並可刪除此分支。

2.2.3 feature/[function] 等輔助分支

從 master 拉取，用於新需求（版本）開發

feature/[function]：功能分支，多人合做開發基於feature分支開發，完成後 merge 回dev分支，並可刪除此分支。
hotfix/*：修復分支，線上發佈後發現線上 bug 後須要從 master 分支拉出來作 bug 修復，*號爲版本號+期次號，完成後 merge 回 master 及 dev 分支，並可刪除此分支
release/：預發佈分支（非必選），從 master 拉取，用於確保當前版本是基於線上最新版本迭代，可處理與線上代碼存在的衝突。任務輔助分支在測試環境經過以後，上預發環境以前，務必拉取一個 release/ 分支。號爲對應的 dev/ 或 hotfix/* 的*

2.3 分支命名

2.3.1 需求（版本）開發

從 master 拉取 dev 分支

分支命名規則：類型 - 版本號

 dev-v2.0.1

 release-v2.0.1複製代碼

Tag命名規則：類型 - 版本號 - 期次號

dev-v2.0.1-102401

release-v2.0.1-102401複製代碼

2.3.2 線上問題處理

從 master 拉取 hotfix 分支

分支命名規則：類型 - hotfix英文簡稱

Tag命名規則：類型 - hotfix英文簡稱 - 期次號

分支：

 hotfix-dateError

 release-dateError複製代碼

Tag:

 hotfix-dateError-102401

 release-dateError-102401複製代碼

3. 代碼管理

管理倉庫的方式，這邊走最普通的 merge 方式：首先會在gitLab上建立一個倉庫，爲當前項目中每位開發人員取一個對應的分支，讓其在對應的分支開發。而後clone這個倉庫。當隊員須要向gitLab上傳代碼時，須要先將本身的代碼同步到本身遠程倉庫對應的分支中，再切換到要本地的主分支將本身本地開發的分支代碼進行合併，若是有衝突先在本地解決，最後再同步到遠程的主分支。