別再亂寫Git Commit了
寫在前面
在很長的一段時間中,使用git commit都是隨心所欲,log肥腸簡潔,隨著代碼的迭代,當(dāng)時有多偷懶,返過頭查看git日志就有多狼狽,就和寫代碼不寫doc string或?qū)懙暮芎唵我粯?,將浪費無數(shù)時間重新瀏覽
其實,git commit格式是有約定的,以下對一些常用進行說明,一起看看吧
插播,更多文字總結(jié)·指南·實用工具·科技前沿動態(tài)第一時間更新在公粽號【啥都會一點的研究生
】
正文
提交commit的結(jié)構(gòu)如下
type
首先是type,必填項,能直觀的向向各使用者傳達進行了哪類型的更新,一般使用較多的為
fix
:用于表明修復(fù)了代碼庫中的bugfeat
:在代碼庫中新增了功能
此外,還有一些其他類型
perf
:在不影響代碼內(nèi)部行為的情況下進行了優(yōu)化,提升性能refactor
:代碼重構(gòu)docs
:只修改了文檔類型的內(nèi)容style
:不影響代碼含義的修改,如刪除空格等test
:測試用例的新增或修改build
:項目構(gòu)建或依賴進行更新revert
:一種特殊情況,如果當(dāng)前commit用于撤銷以前的commit,則必須用該type,后面跟著被撤銷commit的Header。ci
:與 CI(持續(xù)集成服務(wù))有關(guān)的改動,如GitLab CIchore
:其他修改
很多人不知道的是這些type后可以搭配!
用于向使用者表明本次更新較為重要,如feat!: <description>
scope
再是scope,選填,用于闡明本次commit 影響的范圍,如與數(shù)據(jù)預(yù)處理相關(guān)、某模塊功能相關(guān)等
description
必填,顧名思義就是對本次的提交做個簡短概述
以動詞開頭,使用現(xiàn)在時如fix,而不是fixed
第一個字母小寫
結(jié)尾不加句號(.)
body
選填,詳細描述本次的commit,一般小的修改在上面description即可描述清楚,而重大更新盡量把body寫的詳盡,可分行
footer
一般只涉及BREAKING CHANGE和ISSUE相關(guān)
BREAKING CHANGE
:比如涉及重大變更則本部分為必填項,類似版本升級、接口變更等ISSUE相關(guān)
:如當(dāng)前 commit 針對某個issue,可進行引用/關(guān)閉
以下參考www.conventionalcommits.org
例子
帶有description和 breaking change footer的commit
使用
!
提交消息以引起對重大更改的注意
提交帶有范圍和
!
的消息
提交帶有
!
和BREAKING CHANGE footer的消息
提交沒有正文的消息
提交具有多段落body和多個footer的消息
約定規(guī)范
commit必須以type為前綴,類型由名詞(例如feat表示新功能,fix表示修復(fù)等)組成,后面是可選的范圍(scope),可選的感嘆號(!),和必需的冒號(英文半角)和空格
commit后可以提供范圍(scope),必須由括號括起的描述代碼庫部分的名詞組成,例如
fix(parser)
冒號和類型/范圍前綴之后必須立即跟著描述(description),描述是代碼更改的簡短摘要
在簡短描述之后,可以提供較長的正文(body)描述,提供有關(guān)代碼更改的詳細上下文信息。正文必須在description之后的一個空行處開始。
body是自由格式的,可以由任意數(shù)量的用換行符分隔的段落組成
在正文結(jié)束的一個空行之后,可以編寫一行或多行腳注(footer)。腳注必須包含關(guān)于提交的元信息,例如:關(guān)聯(lián)的合并請求、ISSUE相關(guān)、重大變更,每條元信息一行
破壞性變更必須標(biāo)示在正文區(qū)域最開始處,或腳注區(qū)域中某一行的開始
如果將破壞性變更寫在腳注中,必須包含大寫文本
BREAKING CHANGE
,后面緊跟冒號、空格和相關(guān)描述,例如BREAKING CHANGE: environment variables now take precedence over config files.
如果破壞性變更寫在正文,必須在冒號前加上
!
,如果使用!
則可以從腳注部分省略BREAKING CHANGE:?
,并且提交描述將用于描述破壞性更改
以上就是本期的全部內(nèi)容,期待點贊三連,我是啥都生,下次再見