Github的commit規範

參考連接:GIT寫出好的 commit message

基本要求

  • 第一行應該少於50個字。 隨後是一個空行 第一行題目也能夠寫成:Fix issue #8976
  • 永遠不在 git commit 上增長 -m <msg> 或 --message=<msg> 參數,而單獨寫提交信息
  • 一個很差的例子 git commit -m "Fix login bug"git

一個推薦的 commit message 應該是這樣:ruby

Redirect user to the requested page after login

https://trello.com/path/to/relevant/card

Users were being redirected to the home page after login, which is less
useful than redirecting to the page they had originally requested before
being redirected to the login form.

* Store requested path in a session variable
* Redirect to the stored location after successfully logging in the user
  • 註釋最好包含一個鏈接指向大家項目的 issue/story/card。一個完整的鏈接比一個 issue numbers 更好
  • 提交信息中包含一個簡短的故事,能讓別人更容易理解你的項目

小提示

  • 使用 fixaddchange 而不是 fixedaddedchanged
  • 永遠別忘了第2行是空行
  • 用 Line break 來分割提交信息,讓它在某些軟件裏面更容易讀
  • 請將每次提交限定於完成一次邏輯功能。而且可能的話,適當地分解爲屢次小更新,以便每次小型提交都更易於理解。
經常使用type:

feat:新功能(feature)
update:更新
change:修改 fix:修補bug docs:文檔(documentation) style: 格式(不影響代碼運行的變更) refactor:重構(即不是新增功能,也不是修改bug的代碼變更) test:增長測試 chore:構建過程或輔助工具的變更

例子:

Fix bug where user can't signup.

[Bug #2873942]

Users were unable to register if they hadn't visited the plans
and pricing page because we expected that tracking
information to exist for the logs we create after a user
signs up.  I fixed this by adding a check to the logger
to ensure that if that information was not available
we weren't trying to write it.
推薦格式:
        頭部(描述更新的內容)
        //空行
 內容詳細描述 //空行 尾部(加上部分註解等) 
相關文章
相關標籤/搜索