你可能會忽略的 Git 提交規範

Shine-x發表於2019-03-17
Git

一、為什麼需要規範？

  • 無規矩不成方圓，程式設計也一樣。
  • 如果你有一個專案，從始至終都是自己寫，那麼你想怎麼寫都可以，沒有人可以干預你。可是如果在團隊協作中，大家都張揚個性，那麼程式碼將會是一團糟，好好的專案就被糟踐了。不管是開發還是日後維護，都將是災難。
  • 這時候，有人提出了何不統一標準，大家都按照這個標準來。於是 ESLint，JSHint 等程式碼工具如雨後春筍般湧現，成為了專案構建的必備良品。
  • Git Commit 規範可能並沒有那麼誇張，但如果你在版本回退的時候看到一大段糟心的 Commit，恐怕會懊惱不已吧。所以，嚴格遵守規範，利人利己。

二、具體規則

先來看看公式：

<type>(<scope>): <subject>

type
用於說明 commit 的類別，只允許使用下面7個標識。

  • feat：新功能（feature）
  • fix：修補bug
  • docs：文件（documentation）
  • style： 格式（不影響程式碼執行的變動）
  • refactor：重構（即不是新增功能，也不是修改bug的程式碼變動）
  • test：增加測試
  • chore：構建過程或輔助工具的變動

scope

用於說明 commit 影響的範圍，比如資料層、控制層、檢視層等等，視專案不同而不同。

subject

  • 是 commit 目的的簡短描述，不超過50個字元。
  • 以動詞開頭，使用第一人稱現在時，比如change，而不是changed或changes
  • 第一個字母小寫
  • 結尾不加句號(.)

三、異常處理

我們先來看看這個異常提醒：

INVALID COMMIT MSG: does not match "<type>(<scope>): <subject>" ! 
jartto:fix bug

這裡之所以報出這個警告，是因為我的提交出現了兩個問題：

  • 其一，使用了規範外的關鍵字;
  • 其二，很細節的問題，jartto：後少了空格;
  • 這時候我才回憶起來，當時提交一直失敗，情急之下直接強制提交，所以以後的提交都會抱出這個異常。大致意思就是：
  • 你的之前的 Commit 不合格～你的之前的 Commit 不合格～你的之前的 Commit 不合格
  • 這時候就很煩了，我們只能去將之前的錯誤修正，那麼如何操作呢?

四、如何修改之前的 commit 資訊？

其實並不複雜，我們只需要這樣做:

1、將當前分支無關的工作狀態進行暫存

git stash

2、將 HEAD 移動到需要修改的 commit 上

git rebase 9633cf0919^ --interactive

3、找到需要修改的 commit ,將首行的 pick 改成 edit
4、開始著手解決你的 bug
5、 git add 將改動檔案新增到暫存
6、 git commit –amend 追加改動到提交
7、git rebase –continue 移動 HEAD 回最新的 commit
8、恢復之前的工作狀態

git stash pop

大功告成，是不是想把整個 Commit 都修改一遍，逃～

五、專案中使用

這時候問題又來了，為什麼我提交的時候會有警告，這個又是如何做到的呢?
這時候，我們需要一款 Node 外掛 validate-commit-msg 來檢查專案中 Commit message 是否規範。

1、首先，安裝外掛：

npm install --save-dev validate-commit-msg

2、使用方式一，建立 .vcmrc 檔案：

{ 
  "types": ["feat", "fix", "docs", "style", "refactor", "perf", "test", "build", "ci", "chore", "revert"], 
  "scope": { 
    "required": false, 
    "allowed": ["*"], 
    "validate": false, 
    "multiple": false 
  }, 
  "warnOnFail": false, 
  "maxSubjectLength": 100, 
  "subjectPattern": ".+", 
  "subjectPatternErrorMsg": "subject does not match subject pattern!", 
  "helpMessage": "", 
  "autoFix": false 
}

3、使用方式二：寫入 package.json

{ 
  "config": { 
    "validate-commit-msg": { 
      /* your config here */ 
    } 
  } 
}

4、可是我們如果想自動使用 ghooks 鉤子函式呢？

{ 
  … 
  "config": { 
    "ghooks": { 
      "pre-commit": "gulp lint", 
      "commit-msg": "validate-commit-msg", 
      "pre-push": "make test", 
      "post-merge": "npm install", 
      "post-rewrite": "npm install", 
      … 
    } 
  } 
  … 
}

在 ghooks 中我們可以做很多事情，當然不只是 validate-commit-msg 哦。
更多細節請參考：https://github.com/conventional-changelog-...

六、Commit 規範的作用

  • 1、提供更多的資訊，方便排查與回退;
  • 2、過濾關鍵字，迅速定位;
  • 3、方便生成文件;

七、生成 Change log

正如上文提到的生成文件，如果我們的提交都按照規範的話，那就很簡單了。生成的文件包括以下三個部分：

New features
Bug fixes
Breaking changes.

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

npm install -g conventional-changelog 
cd jartto-domo 
conventional-changelog -p angular -i CHANGELOG.md -w

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

{ 
  "scripts": { 
    "changelog": "conventional-changelog -p angular -i CHANGELOG.md -w -r 0" 
  } 
}

這樣，使用起來就很簡單了：

 npm run changelog

你可能不太會用的 10 個 Git 命令

檢查

先了解一下如何檢查改動痕跡。

  • git diff——檢視所有本地檔案的改動。只改動一個檔案的話可以在命令後新增檔名。
  • git log——檢視所有提交歷史。還可用於帶有 git log –p my_file 的檔案，輸入 q 退出。
  • git blame my file——瞭解誰在什麼時候對 my_file 做了什麼樣的改動。
  • git reflog——顯示原生程式碼庫 HEAD 的更改日誌。這個命令很適合查詢丟失的工作。

    用 Git 進行檢查並不麻煩。相比之下，Git 中有不少刪除和撤銷提交以及檔案改動的操作。

撤銷

可以用 git reset、git checkout 和 git revert 撤銷在程式碼庫中所做的改動，這些命令可能有點難理解。

git reset 和 git checkout 既可用於提交也可用於單個檔案的修改，而 git revert 只能用在提交層面。如果你只需要處理尚未合併到協作遠端工作的本地提交，你可以使用這三者中任何一條命令。如果是協同工作且需要撤銷遠端分支中的提交，那麼就用 git revert。

git reset –-hard HEAD——撤銷最近提交以來暫存區和非暫存區的改動。
git checkout my commit——從 my_commit 中撤銷非暫存區的改動。
git revert my commit——撤銷 my_commit 中的更改。當用 revert 撤銷改動時，它會產生新的提交。

注:

之前得帖子有很多的不規範,大家儘管提意見,我一定改正,謝謝.抱拳

本作品採用《CC 協議》，轉載必須註明作者和本文連結

相關文章