關於Git commit

Genius_Spark發表於2018-09-23
GitMIT

git commit 的重要性

當你學會使用git，並在GitHub上建立了自己的Repositories時。

嗯。可以push自己的程式碼了，一頓

  1. git pull origin master
  2. git add .
  3. git commit -m"balabala"
  4. git push origin master

看到100%之後開心極了。幾個月後看到如下

關於Git commit
請問上傳的註冊頁面在哪裡呢？？？想必你也心裡充滿了疑慮，我到底放在哪個裡面的？？

由此可見git add和git commit並不是很簡單的一次全部完成的

正確的使用git add 和 git commit

當你每次push的時候，一定是更新了一些程式碼，完善了一些功能。

例如：

1. 註冊功能
2. 登入功能
3. 完善了README
複製程式碼

那麼該如何的push這次程式碼呢？？

  1. 提交註冊功能的功能程式碼
    git add src/register
    git commit -m"add register function"
複製程式碼
  1. 提交登入功能的程式碼
    git add src/login
    git commit -m"add login function"
複製程式碼
  1. 提交完善的README
    git add READM.md
    git commit -m"modify README"
複製程式碼

做完以上之後，你就可以正常的

git push origin mater
複製程式碼

當然，這樣只是一個簡單push

進一步的規範你的git commit

你以為做到上面這些你就可以完成規範的git commit 了嗎？？

太天真你，一般規範的commit需要由三部分構成

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

其中，Header 是必需的，Body 和 Footer 可以省略。

不管是哪一個部分，任何一行都不得超過72個字元（或100個字元）。這是為了避免自動換行影響美觀。

1.Header

Head這部分只有一行，但是包括三個部分

< type >(必需)< scope >（可選）< subject >（必需）

(1) < type >

type用來說明commit的類別，也就是說別人看了你的type就知道你這次push的性質是什麼，只允許有以下幾種標識

  • init: 初始化專案,往往用於倉庫剛剛建立，建好專案框架之後的一次push
  • feat: 新功能(feature)
  • docs: 文件的提交(document)
  • fix: 修補bug
  • style: 格式的改動(不影響程式碼執行的變動，往往是規範了程式碼的格式)
  • refactor: 重構(既不增加新功能，也不改任何的bug)
  • test: 增加測試
  • chore: 構建過程或輔助工具的變動
  • opt: 優化和改善，比如彈窗進行確認提示等相關的，不會改動邏輯和具體功能等
  • other: 用於難以分類的類別（不建議使用，但一些如刪除不必要的檔案，更新.ignore之類的可以使用）

      如果type為feat和fix，則該 commit 將肯定出現在 Change log 之中。其他情況（docs、chore、style、refactor、test）由你決定，要不要放入 Change log，建議是不要。

(2) < scope >

scope用於說明commit的影響範圍，比如資料層，控制層，檢視層等

      （可選）型別後面可以加上括號，括號內填寫主要變動的範圍，比如按功能模組分，某模組；或按專案三層架構模式分，分資料 層、控制層之類的。

#：表示模組
#student --> 表示 學生模組 （具體的模組開頭字母小寫，駝峰命名）
#ALL --> 表示 所有模組 （特殊含義如ALL表所有，MOST表大部分，用大寫字母表示）
#MOST --> 表示 大部分模組
複製程式碼

e.g. feat(#student): 新增新增學生的功能 —— 表示student模組新增功能，功能是新增學生

(3)< subject >

subject是 commit 目的的簡短描述，不超過50個字元。

- 以動詞開頭，使用第一人稱現在時，比如change，而不是changed或changes
- 第一個字母小寫
- 結尾不加句號（.）
複製程式碼

2. Body

body部分是對本次commit的詳細描述，可以分成多行進行描述可以分成多行，正文在 72 個字元處換行。

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

於是可以這樣寫：

balabala : balabala

what:
balabala

why:
balabala
複製程式碼

3. Footer

Footer只用於兩種情況

(1)不相容變動

如果當前程式碼與上一個版本不相容，則 Footer 部分以BREAKING CHANGE開頭，後面是對變動的描述、以及變動理由和遷移方法。

BREAKING CHANGE: isolate scope bindings definition has changed.

To migrate the code follow the example below:

Before:

scope: {
  myAttr: 'attribute',
}

After:

scope: {
  myAttr: '@',
}

The removed `inject` wasn't generaly useful for directives so there should be no code using it.
複製程式碼

（2）關閉 Issue

如果當前 commit 針對某個issue，那麼可以在 Footer 部分關閉這個 issue 。

Closes #234
複製程式碼

也可以一次關閉多個 issue 。

Closes #123, #245, #992
複製程式碼

4. Revert

還有一種特殊情況，如果當前 commit 用於撤銷以前的 commit，則必須以revert:開頭，後面跟著被撤銷 Commit 的 Header。

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

This reverts commit 667ecc1654a317a13331b17617d973392f415f02.
複製程式碼

Body部分的格式是固定的，必須寫成This reverts commit <hash>.，其中的hash是被撤銷 commit 的 SHA 識別符號。

如果當前 commit 與被撤銷的 commit，在同一個釋出（release）裡面，那麼它們都不會出現在 Change log 裡面。如果兩者在不同的釋出，那麼當前 commit，會出現在 Change log 的Reverts小標題下面。

幾個優秀的撰寫合格的commit的工具

1. Commitizen

Commitizen是一個撰寫合格 Commit message 的工具。

安裝命令如下。

$ npm install -g commitizen
複製程式碼

然後，在專案目錄裡，執行下面的命令，使其支援 Angular 的 Commit message 格式。

$ commitizen init cz-conventional-changelog --save --save-exact
複製程式碼

以後，凡是用到git commit命令，一律改為使用git cz。這時，就會出現選項，用來生成符合格式的 Commit message。

關於Git commit

2. validate-commit-msg

validate-commit-msg 用於檢查 Node 專案的 Commit message 是否符合格式。

它的安裝是手動的。首先，拷貝下面這個JS檔案，放入你的程式碼庫。檔名可以取為validate-commit-msg.js。

接著，把這個指令碼加入 Git 的 hook。下面是在package.json裡面使用 ghooks，把這個指令碼加為commit-msg時執行.

"config": {
  "ghooks": {
    "commit-msg": "./validate-commit-msg.js"
  }
}
複製程式碼

然後，每次git commit的時候，這個指令碼就會自動檢查 Commit message 是否合格。如果不合格，就會報錯。

$ git add -A 
$ git commit -m "edit markdown" 
INVALID COMMIT MSG: does not match "<type>(<scope>): <subject>" ! was: edit markdown
複製程式碼

3. conventional-changelog

如果你的所有 Commit 都符合 Angular 格式，那麼釋出新版本時， Change log 就可以用指令碼自動生成。

生成的文件包括以下三個部分。

- New features
- Bug fixes
- Breaking changes.
複製程式碼

每個部分都會羅列相關的 commit ，並且有指向這些commit的連結。當然，生成的文件允許手動修改，所以釋出前，你還可以新增其他內容。

conventional-changelog 就是生成 Change log 的工具，執行下面的命令即可。

$ npm install -g conventional-changelog
$ cd my-project
$ conventional-changelog -p angular -i CHANGELOG.md -w
複製程式碼

上面命令不會覆蓋以前的 Change log，只會在CHANGELOG.md的頭部加上自從上次釋出以來的變動。

如果你想生成所有釋出的 Change log，要改為執行下面的命令。

$ conventional-changelog -p angular -i CHANGELOG.md -w -r 0
複製程式碼

為了方便使用，可以將其寫入package.json的scripts欄位。

{
  "scripts": {
    "changelog": "conventional-changelog -p angular -i CHANGELOG.md -w -r 0"
  }
}
複製程式碼

以後，直接執行下面的命令即可。

$ npm run changelog
複製程式碼

(完)

以上內容僅代表作者自己的個人觀點，歡迎廣大專業人士提出建議

Thank You！！

相關文章