create by db on 2021-1-25 16:34:46
Recently revised in 2021-1-25 19:34:56前端

閒時要有吃緊的心思，忙時要有清閒的趣味python

本文已參與好文召集令活動，點擊查看：後端、大前端雙賽道投稿，2萬元獎池等你挑戰webpack

目錄git

前言github
正文web
總結npm

前言

返回目錄編程

無規矩不成方圓，編程也同樣。後端

若是你有一個項目，從始至終都是本身寫，那麼你想怎麼寫均可以，沒有人能夠干預你。但是若是在團隊協做中，你們都張揚個性，那麼代碼將會是一團糟，好好的項目就被糟踐了。不論是開發仍是往後維護，都將是災難。

這時候，有人提出了何不統一標準，你們都按照這個標準來。因而 ESLint，JSHint 等代碼工具如雨後春筍般涌現，成爲了項目構建的必備良品。

Git Commit 規範可能並無那麼誇張，但若是你在版本回退的時候看到一大段糟心的 Commit，恐怕會懊惱不已吧。因此，嚴格遵照規範，利人利己。

正文

返回目錄

提交規範的做用

大多數狀況下，看提交歷史的人跟提交代碼的人都不是同一我的，當別人閱讀你的提交歷史時，他極可能是不知道具體代碼細節的，你如何在最短的時間內讓他一眼知道每次提交的意義：

每次提交影響的具體範圍？
這個 bug 在哪次提交中被修復了？
這個新功能是在哪次提交中增長的？
修改是否向下兼容？
是否回滾了代碼？
是否只是修改了文檔、調整了代碼格式？
是否修改了測試、是否進行了重構？
是否對代碼進行了性能優化？

提交規範的格式

用什麼規範？

如今市面上比較流行的方案是約定式提交規範（Conventional Commits），它受到了 Angular 提交準則的啓發，並在很大程度上以其爲依據。

約定式提交規範是一種基於提交消息的輕量級約定。它提供了一組用於建立清晰的提交歷史的簡單規則；這使得編寫基於規範的自動化工具變得更容易。這個約定與 SemVer 相吻合，在提交信息中描述新特性、bug 修復和破壞性變動。

它的 message 格式以下:

<type>[optional scope]: <description> // header
// 空一行
[optional <body>]
// 空一行
[optional <footer(s)>]

複製代碼

舉個簡單的例子：

feat(config): 容許 config 對象直接從其餘 config 繼承

BREAKING CHANGE: 在 config 對象中增長 `extends` 字段，用於從其餘繼承 config

close issue #23
複製代碼

固然咱們也能夠寫的簡潔一些

feat: 容許 config 對象直接從其餘 config 繼承
複製代碼

注：

在命令行裏 git commit 時，若是你想進行多行 commit 編輯，能夠經過 git commit -a 進入編輯界面；若是是單行，能夠直接 git commit -m 'COMMIT MESSAGE' 完成提交。

格式講解

一. header(必填)

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

總的來講，關鍵就是 header 這部分，至於<body>和<footer(s)>可省略

例如:

feat:新增財務報表
複製代碼

1. type(必填)

type 爲必填項，用於指定 commit 的類型，約定了 feat、fix 兩個主要 type，以及 docs、style、build、refactor、revert 五個特殊 type，其他 type 暫不使用。（參考人人貸大前端技術中心）

# 主要type
feat:     增長新功能
fix:      修復bug

# 特殊type
docs:     只改動了文檔相關的內容
style:    不影響代碼含義的改動，例如去掉空格、改變縮進、增刪分號
build:    構造工具的或者外部依賴的改動，例如webpack，npm
refactor: 代碼重構時使用
revert:   執行git revert打印的message

# 暫不使用type
test:     添加測試或者修改現有測試
perf:     提升性能的改動
ci:       與CI（持續集成服務）有關的改動
chore:    不修改src或者test的其他修改，例如構建過程或輔助工具的變更
複製代碼

注：

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

2. scope(選填)

可選項，用來講明這次修改的影響範圍，格式爲項目名/模塊名，能夠是一個文件的地址，如 /lib/utils；也能夠是某個功能點 parser，不建議超過兩個單詞

如：

.all       //表示影響面大 ，如修改了網絡框架 會對真個程序產生影響
.loation   //表示影響小，某個小小的功能
.module    //表示會影響某個模塊 如登陸模塊、首頁模塊 、用戶管理模塊等等
複製代碼

注：

若是一次 commit 修改多個模塊，建議拆分紅屢次 commit，以便更好追蹤和維護。

3. description(必填)

必填項，是 commit 目的的簡短描述，不超過 50 個字符。

規範以下：

以動詞開頭，使用第一人稱如今時，好比 change，而不是 changed 或 changes
第一個字母小寫
結尾不加句號（.）

二. body(選填)

可選項，具體的修改信息應該儘可能詳細，通常不用寫。

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

三. footer(s)(選填)

可選項，放置備註啥的，若是是 bug ，能夠把 bug id 放入，通常不用寫。

commitizen

這個一款基於 Node 的交互式約束命令工具，適合喜歡使用命令行的小夥伴。

使用詳情請參考 Git commit message 規範 | 掘金 - 人人貸大前端技術中心

git 設置模板

對於喜歡使用如sourceTree同樣有着界面的git工具的同窗，就能夠採用 git 配置模板的方式。

使用詳情請參考老鳥都應該注意的git 提交規範| 博客園 - Four two

總結

返回目錄

固然了，實際中，也不必定要採用這種規則，可是你能夠借鑑它的，而後本身那邊再根據實際狀況變更。

提交規範在於之後維護方面是很是有利的，先不說遠的，近的話，使用 Git 時，合併代碼一般會有衝突，有些突發意外，好比另外的人不當心將你的代碼覆蓋了，並且這個功能已是好久以前的了，那怎麼辦呢？一般狀況，本地有備份當然好，可是估計也沒有那我的會將本身每次提交，都本地保存一份，由於那樣顯得效率低下和根據項目的週期和需求，項目愈來愈大，這樣的話，本地備份的包也會愈來愈多。沒有人會選擇這種方式。最後的方式就是版本回退，固然了，前提是你提交信息必須簡潔明瞭，否則的話像鬼知道是哪一個。

另外關於何時提交，儘量是完成一個新的功能或者是優化某個功能，解決某個 bug 等等就提交。可是這裏有個前提就是，你本地必須測試沒有問題，不然那樣等於作無用工。

路漫漫其修遠兮，與諸君共勉。

參考文獻：

後記：Hello 小夥伴們，若是以爲本文還不錯，記得點個贊或者給個 star，大家的贊和 star 是我編寫更多更豐富文章的動力！GitHub 地址

文檔協議

db 的文檔庫由 db 採用知識共享署名-非商業性使用-相同方式共享 4.0 國際許可協議進行許可。
基於 github.com/danygitgit上的做品創做。
本許可協議受權以外的使用權限能夠從 creativecommons.org/licenses/by… 處得到。

關於 Git 提交規範

前言

正文