1.1 緣由

重建一段代碼的上下文是一種浪費(fèi)。我們不能完全避免，我們只能努力盡最大可能去減少它。提交的信息就可以做到這一點(diǎn)，以至于一個(gè)提交信息可以表明一個(gè)開發(fā)者是不是一個(gè)好的合作者。

如果你對(duì)如何寫好 git 提交信息沒有仔細(xì)想過，那你很可能沒有怎么使用過 git log 和相關(guān)工具。這里有一個(gè)惡性循環(huán)：因?yàn)樘峤坏臍v史信息組織混亂而且前后矛盾，那后面的人也就不愿意花時(shí)間去使用和維護(hù)它。 又因?yàn)闆]有人去使用和維護(hù)它，提交的信息就會(huì)一直組織混亂和前后矛盾。

1.2 作用

• 提供更多的歷史信息，方便快速瀏覽。

//下面的命令顯示上次發(fā)布后的變動(dòng)，每個(gè)commit占據(jù)一行。你只看行首，就知道某次 commit 的目的。
git log <last tag> HEAD --pretty=format:%s

• 可以過濾某些commit（比如文檔改動(dòng)），便于快速查找信息。
• 可以直接從commit生成Change log。

1.2 目的

統(tǒng)一團(tuán)隊(duì)git commit 團(tuán)隊(duì)日志標(biāo)準(zhǔn)，便于后續(xù)代碼review和發(fā)布版本

2 規(guī)范

基于使用最廣泛的angular日志規(guī)范
。
分為三部分：標(biāo)題、內(nèi)容、結(jié)尾，其中，==標(biāo)題==是==必需==的，內(nèi)容無需過多描述的話，正文內(nèi)容部分可以省略。

不管是哪一個(gè)部分，任何。一行都不得超過72個(gè)字符（或100個(gè)字符）。這是為了避免自動(dòng)換行影響美觀

<類型>(范圍): <主題>
// 空一行
<內(nèi)容>
// 空一行
<Footer>

2.1 標(biāo)題

1. 標(biāo)題部分只有一行，包括字段：類型 和 主題。
2. 標(biāo)題限制總字?jǐn)?shù)在50個(gè)字符以內(nèi)，以保證容易閱讀。

feat: init LearnGit.git

I got a wrong-style git commit, so I init a .git for learning
how to write a git commit message in right way.

And the last line just write here for a simple test,
it's useless acturally.

2.1.1 類型

類型用于說明 commit 的類別，只允許使用下面7個(gè)標(biāo)識(shí)。

• init：項(xiàng)目初始化（用于項(xiàng)目初始化或其他某種行為的開始描述，不影響代碼）
• feat：新功能（feature）
• fix：修補(bǔ)bug
• docs：文檔（documentation）
• opt：優(yōu)化和改善，比如彈窗進(jìn)行確認(rèn)提示等相關(guān)的，不會(huì)改動(dòng)邏輯和具體功能等
• style： 格式（不影響代碼運(yùn)行的變動(dòng)）
• refactor：重構(gòu)（即不是新增功能，也不是修改bug的代碼變動(dòng)）
• test：增加測(cè)試
• other：用于難以分類的類別（不建議使用，但一些如刪除不必要的文件，更新.ignore之類的可以使用）

2.1.2 范圍

類型后面可以加上括號(hào)，括號(hào)內(nèi)填寫主要變動(dòng)的范圍，比如按功能模塊分，某模塊；或按項(xiàng)目三層架構(gòu)模式分，分?jǐn)?shù)據(jù)層、控制層之類的。
#：表示模塊
- #market--> 表示 商城模塊 （具體的模塊開頭字母小寫，駝峰命名）
- #ALL --> 表示 所有模塊 （特殊含義如ALL表所有，MOST表大部分，用大寫字母表示）
- #MOST --> 表示 大部分模塊

feat(#market): 新增添商城功能 

2.1.3 主題

主題 是 commit 目的的簡(jiǎn)短描述，不超過50個(gè)字符。

• 第一個(gè)字母小寫
• 以動(dòng)詞開頭
• 結(jié)尾不加句號(hào)

2.2 內(nèi)容

內(nèi)容部分是對(duì)本次 commit 的詳細(xì)描述，可以分成多行，正文在 72 個(gè)字符處換行。

使用正文解釋是什么(what)和為什么(why)，而不是如何做，以及與以前行為的對(duì)比。

2.3 Footer

Footer 部分只用于兩種情況：

1. 不兼容變動(dòng)

   如果當(dāng)前代碼與上一個(gè)版本不兼容，則 Footer 部分以BREAKING
   CHANGE開頭，后面是對(duì)變動(dòng)的描述、以及變動(dòng)理由和遷移方法。

2. 關(guān)閉 Issue

   如果當(dāng)前 commit 針對(duì)某個(gè)issue，那么可以在 Footer 部分關(guān)閉這個(gè) issue 。

Closes #123, #245, #992

2.4 Revert

還有一種特殊情況，如果當(dāng)前 commit 用于撤銷以前的 commit，則必須以revert:開頭，后面跟著被撤銷 Commit 的 Header。

revert: feat(pencil): add 'graphiteWidth' option

This reverts commit 667ecc1654a317a13331b17617d973392f415f02.

Body部分的格式是固定的，必須寫成This reverts commit <hash>.，其中的hash是被撤銷 commit 的 SHA 標(biāo)識(shí)符。

3 工具

3.1 Commitizen

Commitizen是一個(gè)格式化commit message的工具。通過上面安裝好的npm來安裝：

npm install -g commitizen

而我們用的是Angular的commit message規(guī)范，那么就在我們項(xiàng)目的目錄下輸入以下命令：

commitizen init cz-conventional-changelog --save --save-exact

生成package.json文件，有時(shí)候這個(gè)文件名會(huì)錯(cuò)誤，需要手動(dòng)修改文件名。或者：

先在項(xiàng)目中添加一個(gè)空的package.json文件，然后再輸入始化配置package.json文件命令：

npm init --yes

然后輸入：

commitizen init cz-conventional-changelog --save --save-exact

接下來在提交的時(shí)候，就用git cz替換git commit命令，會(huì)出現(xiàn)提交類型的選擇，選擇相應(yīng)類型就好。

commitizen

3.2 生成CHANGELOG

conventional-changelog就是生成 Change log 的工具。

運(yùn)行下列命令：

$ npm install -g conventional-changelog
$ cd my-project
$ conventional-changelog -p angular -i CHANGELOG.md -w

如果最后出現(xiàn)command not found，就要改用conventional-changelog-cli：

$ npm install -g conventional-changelog-cli
$ cd my-project
$ conventional-changelog -p angular -i CHANGELOG.md -s

通過以上命令你就會(huì)發(fā)現(xiàn)在項(xiàng)目中多了個(gè)CHANGELOG.md文件，表示生成 Change log成功了。