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

hlcc 發布于2019-08-02 10:28 / 953人閱讀

摘要：隨著團隊的變大，最近在開發過程中，越來越感覺到的重要性。注意年月日，阮一峰老師寫了一篇和編寫指南，本文主要來源于這篇文章，只是針對我們的團隊，進行了一些改造和簡化，以及對一些阮老師沒有提及的細小之處進行了指出。

隨著團隊的變大，最近在開發過程中，越來越感覺到commit log的重要性。之前的時候，團隊內有人寫中文log，有人寫英文log；有人寫的還算清晰，有人一筆更新bug就概括全貌。這些良莠不齊的commit log充斥在我們的項目中，不僅影響了查閱的效果，還會對code review產生負面的影響。因此，本文是意圖從commit log的書寫規范入手，并提供相應的解決方案。

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

1. 書寫規范

經過一番調研，因為我們是小團隊，需要快速迭代，容易上手，所以對阮老師提到的commit log規范進行了簡化，具體如下：

1.1 type

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

feat: 新功能

fix: 修復問題

docs: 修改文檔

style: 修改代碼格式，不影響代碼邏輯

refactor: 重構代碼，理論上不影響現有功能

perf: 提升性能

test: 增加修改測試用例

revert: 回退，建議直接使用Github Desktop回退，而不是使用命令

1.2 subject

用一句話清楚的描述這次提交做了什么。書寫要遵循以下四種規則：

格式盡量使用謂賓，使用謂賓不通順時，可以使用主謂，例如：

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

除了名稱之外，描述盡可能使用中文，方便不同開發者理解

結尾不加句號

描述控制在20個漢字以內

1.3 body

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

2. 撰寫工具

有工具輔助，一定比手寫好，這里我們使用Commitizen這個庫。
安裝命令：

cd 項目目錄
npm install -g commitizen
commitizen init cz-conventional-changelog --save --save-exact
// 項目做些更改之后
git add .
git cz

安裝完畢之后，使用git cz來代替git commit命令即可，新的commit log提交界面會如下所示：

寫完了之后的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分支中。這一塊我覺得天豬說的很有道理，通過人工的手段去實現這種驗證，這也是為了大家養成一個良好的代碼習慣。

參考文檔：

《Commit message 和 Change log 編寫指南》

《代碼貢獻規范》

GPU云服務器云服務器 api設計的最佳實踐最佳實踐 webrtc最佳實踐 cdn最佳實踐

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/52378.html

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

摘要：隨著團隊的變大，最近在開發過程中，越來越感覺到的重要性。注意年月日，阮一峰老師寫了一篇和編寫指南，本文主要來源于這篇文章，只是針對我們的團隊，進行了一些改造和簡化，以及對一些阮老師沒有提及的細小之處進行了指出。隨著團隊的變大，最近在開發過程中，越來越感覺到commit log的重要性。之前的時候，團隊內有人寫中文log，有人寫英文log；有人寫的還算清晰，有人一筆更新bug就概括全貌...

go4it 2019-08-22 18:23 評論0 收藏0
容器環境下的持續集成最佳實踐：構建基于 Drone + GitFlow + K8s 的云原生語義化

摘要：集成測試完成后，由運維同學從發起一個到分支，此時會會運行單元測試，構建鏡像，并發布到預發布環境測試人員在預發布環境下再次驗證功能，團隊做上線前的其他準備工作運維同學合并，將為本次發布的代碼及鏡像自動打上版本號并書寫，同時發布到生產環境。云原生 (Cloud Native) 是伴隨的容器技術發展出現的的一個詞，最早出自 Pivotal 公司（即開發了 Spring 的公司）的一本技術小...

asoren 2019-06-28 17:10 評論0 收藏0
容器環境下的持續集成最佳實踐：構建基于 Drone + GitFlow + K8s 的云原生語義化

摘要：集成測試完成后，由運維同學從發起一個到分支，此時會會運行單元測試，構建鏡像，并發布到預發布環境測試人員在預發布環境下再次驗證功能，團隊做上線前的其他準備工作運維同學合并，將為本次發布的代碼及鏡像自動打上版本號并書寫，同時發布到生產環境。云原生 (Cloud Native) 是伴隨的容器技術發展出現的的一個詞，最早出自 Pivotal 公司（即開發了 Spring 的公司）的一本技術小...

DevTalking 2019-07-01 17:13 評論0 收藏0
《Node.js在CLI下的工程化體系實踐》成都OSC源創會分享總結

摘要：之后，在本地目錄生成代碼并且安裝項目依賴的包，最后將本次初始化生成的所有代碼自動提交到遠程倉庫。按照城市評選，分別評選明日之子僅限男性參加和閃亮女神僅限女性參加。背景: 隨著開發團隊規模不斷發展壯大，在人員增加的同時也帶來了協作成本的增加，業務項目越來越多，類型也各不相同。常見的類型有組件類、活動類、基于React+redux的業務項目、RN項目、Node.js項目等等。如果想要對每...

imingyu 2019-08-21 16:46 評論0 收藏0