快捷導(dǎo)航

怎樣寫好commit?message提高業(yè)務(wù)效率

更新時(shí)間：2023年05月12日 14:36:37 作者：ag9920

這篇文章主要為大家介紹了如何寫好commit?message幫助業(yè)務(wù)團(tuán)隊(duì)提高效率方法詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪

commit 粒度

commit message 在工程開發(fā)中有很重要的作用。一個(gè)好的 message 不僅僅能夠降低 reviewer 的心智負(fù)擔(dān)，也能夠方便日后追蹤問題。但寫好一個(gè) commit message 可不容易，今天這篇文章我們來思考一下怎樣讓 commit message 更加清晰，幫助業(yè)務(wù)團(tuán)隊(duì)提高效率。

commit 本質(zhì)就是一些代碼變更的聚合體，我們可能在一個(gè) commit 中改動(dòng)多個(gè)文件。問題的關(guān)鍵在于 commit 的語義和粒度。

這個(gè)很多時(shí)候很頭疼，大 commit 不好 review，每次一看到十幾個(gè)文件上千行記錄在一個(gè) commit 里就很想哭。小 commit 本身是沒問題的，但很多時(shí)候大家稍微改一點(diǎn)就提一個(gè) commit，導(dǎo)致放眼望去全是意義不大的提交，記錄基本沒法看。

怎么把握這個(gè)度呢？

這里提供一個(gè)標(biāo)準(zhǔn)供大家參考：你的 commit 能得體地告訴別人干了一件什么事。

一件事

能拆的要拆，兩個(gè)語義獨(dú)立的改動(dòng)不要放到一個(gè) commit 里面，做好一件事即可，commit 的內(nèi)容應(yīng)該是高內(nèi)聚的，不要出現(xiàn)夾帶私活的情況。

只要保證你的 Merge Request 是干凈的，信息清晰的就 ok，不要擔(dān)心一個(gè) MR 對(duì)應(yīng)多個(gè) commit 的問題，該合并就合并，但語義獨(dú)立的兩件事，不要合在一起寫。

得體

不要隨隨便便改一個(gè)地方就提交一次，比如這里加了個(gè)空行，那里刪了個(gè)注釋，全拆開，倒的確是不同的事，但這樣讓別人看就很不得體。想象一下，你現(xiàn)在是個(gè)教練，本來可以等學(xué)員練習(xí)好了，看一遍效果給出評(píng)價(jià)即可，可你的學(xué)生每做一個(gè)動(dòng)作就要把你拉過來看看，這時(shí)你是什么心態(tài)？肯定要崩潰！

軟件開發(fā)也是如此，明明你是要開發(fā)一個(gè)需求，結(jié)果只有一個(gè) commit 是真正支撐需求的，各種格式優(yōu)化的 commit 多達(dá)十幾個(gè)，這就非常不得體。

思考每一個(gè) commit 是否必須。一定要記住，不要多寫一行多余的代碼，否則未來你會(huì)很糾結(jié)；
學(xué)會(huì)歸納。合并同類項(xiàng)。

message 格式

<type>(<scope>): <subject>
<空行>
<body>
<空行>
<footer>

type

type 就是 commit 的類型：

docs: 文檔變更
feat: 新需求特性
fix: 修復(fù) bug
perf: 性能提升
style: 代碼風(fēng)格相關(guān)
test: 測試代碼修改
refactor: 重構(gòu)代碼
chore: 構(gòu)建過程或輔助工具的變動(dòng)，日常的修改

scope

scope用于說明 commit 影響的范圍，比如數(shù)據(jù)層、控制層、視圖層等等，視項(xiàng)目不同而不同。這個(gè)大家根據(jù)業(yè)務(wù)情況自行約定規(guī)范即可。

subject

commit message 的核心部分，說明干了一件什么事，標(biāo)題性質(zhì)，簡單的修改要做到讓大家一看標(biāo)題就能理解改了什么。

body

對(duì)本次 commit 的詳細(xì)描述，可以分成多行，說明代碼變動(dòng)的動(dòng)機(jī)，以及與以前行為的對(duì)比，詳細(xì)的背景要在這里說清楚。比如

More detailed explanatory text, if necessary.  Wrap it to 
about 72 characters or so. 
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Use a hanging indent

只有在 break change 或者關(guān)閉 issue 時(shí)使用，場景較少，日常業(yè)務(wù)開發(fā)可以忽略。事實(shí)上，能把 subject，body 寫好就不容易了。

內(nèi)容多了怎么辦

很多時(shí)候大家都直接用 git commit -m "xxx" 來代替，其實(shí)建議大家?guī)?body，很多 commit 光看 subject 跟沒看是一樣的。

這種情況下，大家直接用 git commit 來提交，跳出文本編輯器，支持大家輸入 body。

一定記住，body 不是可有可無，一個(gè)優(yōu)秀的 commit message 要能做到看了就知道前因后果，知道改動(dòng)原因。而不是留一句片湯話在 subject 上。

語言選擇

這一點(diǎn)很多團(tuán)隊(duì)會(huì)忽視，筆者待過的幾乎每個(gè)團(tuán)隊(duì)，都是中英文混雜，這一點(diǎn)很不好。建議統(tǒng)一語言，如果公司規(guī)定開發(fā)必須用【英語】，ok 沒問題，大家做好準(zhǔn)備，提高英語素養(yǎng)，找到每個(gè)業(yè)務(wù)概念最精準(zhǔn)的表達(dá)，形成規(guī)范，落地就行。

但是，但是?。?！

絕大多數(shù)團(tuán)隊(duì)是做不到這一點(diǎn)的，因?yàn)闆]有動(dòng)力，而且大家都是中國人，很多語言表達(dá)即便過了四六級(jí)，也很難很精準(zhǔn)，于是寫的五花八門。

與其這樣，不如明確，除了 type，其他全用中文代替。

以上就是怎樣寫好commit message提高業(yè)務(wù)效率的詳細(xì)內(nèi)容，更多關(guān)于commit message提高效率的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

您可能感興趣的文章: