Git Commit Log的小型團隊最佳實踐

時間 2019-11-07

標籤 git commit log 小型團隊最佳實踐欄目 Git 简体版

原文原文鏈接

隨着團隊的變大，最近在開發過程當中，愈來愈感受到commit log的重要性。以前的時候，團隊內有人寫中文log，有人寫英文log；有人寫的還算清晰，有人一筆更新bug就歸納全貌。這些參差不齊的commit log充斥在咱們的項目中，不只影響了查閱的效果，還會對code review產生負面的影響。所以，本文是意圖從commit log的書寫規範入手，並提供相應的解決方案。

注意：2016年1月6日，阮一峯老師寫了一篇《Commit message 和 Change log 編寫指南》，本文主要來源於這篇文章，只是針對咱們的團隊，進行了一些改造和簡化，以及對一些阮老師沒有說起的細小之處進行了指出。javascript

1. 書寫規範

通過一番調研，由於咱們是小團隊，須要快速迭代，容易上手，因此對阮老師提到的commit log規範進行了簡化，具體以下：html

<type>: <subject>
<body>

1.1 type

提交 commit 的類型，包括如下幾種java

feat: 新功能
fix: 修復問題
docs: 修改文檔
style: 修改代碼格式，不影響代碼邏輯
refactor: 重構代碼，理論上不影響現有功能
perf: 提高性能
test: 增長修改測試用例
revert: 回退，建議直接使用Github Desktop回退，而不是使用命令

1.2 subject

用一句話清楚的描述此次提交作了什麼。書寫要遵循如下四種規則：git

格式儘可能使用謂賓，使用謂賓不通順時，可使用主謂，例如：

謂賓：修復xxxx
主謂：中間件支持xxxx

除了名稱以外，描述儘量使用中文，方便不一樣開發者理解
結尾不加句號
描述控制在20個漢字之內

1.3 body

對本地提交的詳細描述，不建議。咱們建議屢次少許提交，而不是一次巨量的提交，有助於revert和code review，也對災難存儲有容災。npm

2. 撰寫工具

有工具輔助，必定比手寫好，這裏咱們使用Commitizen這個庫。
安裝命令：windows

cd 項目目錄
npm install -g commitizen
commitizen init cz-conventional-changelog --save --save-exact
// 項目作些更改以後
git add .
git cz

安裝完畢以後，使用git cz來代替git commit命令便可，新的commit log提交界面會以下所示：
bash

寫完了以後的commit log以下圖所示：
工具

是否是比以前的commit log看起來清晰不少？
注意：
git bash在windows下不能經過箭頭符號上下移動選擇，這時候咱們能夠下載Cmder來做爲咱們的命令行工具。性能

2. 使用問題

1. commit log 我用20個字描述不清楚怎麼辦？
咱們指望儘量屢次的提交，一個feature提交一次，不要出現積攢多個feature提交狀況，既不有利於code review，也不有利於代碼revert測試

2. 爲何不使用強制驗證手段來限制commit log的格式？
儘管沒有使用自動化驗證的手段（阮老師的文章中提到了，能夠自行查看），可是若是不符合書寫邏輯的話，code reviewer不該該讓其merge request到dev分支中。這一塊我以爲天豬說的頗有道理，經過人工的手段去實現這種驗證，這也是爲了你們養成一個良好的代碼習慣。