git log 生成 changeLog
在進行git倉庫的自動化管理時，發佈前往往需要CI服務器自動生成 CHANGELOG.MD ，本文介紹如何自動changeLog.md自動生成的思路。
文章目錄
生成流程
- 多次 commit -m “xxx”
- 使用命令
git log > log生成提交記錄 log 文件 - 處理 log 文件提取關心的信息, 然後轉成
CHANGELOG.MD文件.- 思路：（log文件中包含了所有的commit信息, 包括id, author, date以及comment等）
- 前提：需要規範團隊 git commit 的格式，才能保證自動生成
爲什麼基於commit的, 不是基於merge？
因爲merge信息的獲取需要使用gitlab提供的API, 不如獲取commit來的方便（'git log > log’一條命令即可）。大多數的開源倉庫的changelog也是基於commit
關鍵問題
- 如何規範團隊 git commit 的格式？
這個問題並不是難題，關鍵是如何讓團隊成員容易掌握提交格式（簡單通用），又方便程序處理（格式規範），我們可以聯想到使用提交模板來解決。
- 可以對 git 客戶端進行增強（如 IDEA 的插件）
- 但如果某些成員不用 IDEA ，那就不能輕鬆的記住提交格式
-
使用 Git 自帶的提交模板 Commit Template 來解決
在命令行裏 git commit 時，自動使用設置的編輯器打開設置的模板。開發者只需在預設模板的基礎上添加或修改相應內容即可。（個人項目通常選擇這種方式，簡單）
一、在工程的根目錄下建立模板文件
新建 gitcommit_template 文件，將希望的模板填充進去：
- 例1：
[部門][項目]:
問題原因:
解決方法:
變更類別:
適用機型:
驗證建議:
關聯變更項：
任務 Id:
- 例2：
# head: <type>(<scope>): <subject>
# - type: feat, fix, docs, style, refactor, test, chore
# - scope: can be empty (eg. if the change is a global or difficult to assign to a single component)
# - subject: start with verb (such as 'change'), 50-character line#
# body: 72-character wrapped. This should answer:
# * Why was this change necessary?
# * How does it address the problem?
# * Are there any side effects?#
# footer:
# - Include a link to the ticket, if any.
# - BREAKING CHANGE
# Commitizen
二、設置模板
有以下幾種設置方式
-
設置當前分支的提交模板
git config commit.template [模板文件名]
如：git config commit.template gitcommit_template -
設置全局的提交模板
git config --global commit.template [模板文件名]
如：git config --global commit.template gitcommit_template -
設置文本編輯器
git config -global core.editor [編輯器名稱]
如:git config -global core.editor vim
三、提交代碼
在命令行裏 git commit 時，自動使用設置的編輯器打開設置的模板。在預設模板的基礎上添加或修改相應內容即可。
然後git push提交到遠程分支。
以工具的方式解決
模板的方式是git原生支持的，模板也可以自定義，定製性強，但與工具相比還不夠方便，下面介紹幾種這方面的工具。
- conventional-changelog
- commitizen
- conventional-changelog-cli
- standard-version
其他
git commit 格式基本規約：50/72格式化
- 第一行不超過50個字符
- 然後是空白行
- 其餘文字應以72個字符換行
原因：
- 一些工具將第一行作爲主題行，將第二段作爲正文(類似於電子郵件)。若工具流行，那麼該格式將流行。
git log不處理換行，因此如果行太長則很難閱讀。git format-patch --stdout可以將提交轉換爲電子郵件。
git commit 風格
不同的人，有不同的表達風格，還有很多風騷的格式，如用 emoji 的, 用唐詩的, 用隨機生成的. 風格沒有對錯, 只要能夠體現出 commit 所做的修改即可。但規範 git commit 的風格有利於倉庫的維護和新加入團隊成員的快速上手。
目前比較建議的是，使用終端工具
commitizen/cz-cli + commitizen/cz-conventional-changelog + conventional-changelog/standard-version 一步解決提交信息和版本發佈。
如果希望強制執行，可以在持續集成裏面加入 marionebl/commitlint 檢查 commit 信息是否符合規範。
目前規範使用較多的是 Angular 團隊的規範, 繼而衍生了 Conventional Commits specification. 很多工具也是基於此規範, 它的 message 格式分爲三行，這三行的詳細介紹如下
標題: 【必填】 簡單描述修改類型和內容
正文內容: 對本次提交的詳細介紹，如爲什麼修改，怎麼修改的,，開發思路是什麼等等
頁腳註釋: 放 Breaking Changes 或 Closed Issues
模板：
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
其中
<>尖括號中的爲具體內容，<BLANK LINE>爲空行。
詳細說明：
type: 修改類型feat: 新特性fix: 修改問題refactor: 代碼重構docs: 文檔修改style: 代碼格式修改， 注意不是 css 修改test: 測試用例修改chore: 其他修改， 比如構建流程， 依賴管理。revert: 用於撤銷以前的 commit 詳見後面特殊情況註釋。
scope: 影響的範圍， 一般爲自己代碼的模塊名。subject: 概述。建議符合 50/72 格式。body: 具體修改內容， 可以分爲多行。建議符合 50/72 格式。footer: 一些備註， 通常是 BREAKING CHANGE 或修復的 bug 的鏈接。
特殊情況【回滾，Revert】：如果當前 commit 用於撤銷以前的 commit，
必須以revert:開頭，後面跟着被撤銷 Commit 的 Header。
Body部分的格式是固定的，必須寫成This reverts commit <hash>.，其中的hash是被撤銷 commit 的 SHA 標識符。
如果當前 commit 與被撤銷的 commit，在同一個發佈（release）裏面，那麼它們都不會出現在 Change log 裏面。
如果兩者在不同的發佈，那麼當前 commit，會出現在 Change log 的Reverts小標題下面。