总有理由
本人半强迫症患者一枚,看到各种提交
fix bug xxx
,甚至连xxx
都没有,在回溯问题的时候一头雾水,只能逐个文件找问题。难。。。
所以个人认为Git Message成为回溯问题的一个迅速确定问题的关键。
那什么样的Message是优秀的呢? 原则又是什么呢?就拿我们一直团队实践的准则来说一说。
提交代码有原则(粒度)
项目代码稳定之后,每次提交都要考虑提交的粒度问题,尽量做到 baby step
- 没有关联的代码不能一次commit提交
- 关联代码一次提交;若内容很多,可内部分层,依次提交
可以根据当前代码模块情况处理。
必须提交Commit Message
- 没有Commit Message 当然不能提交
- 不在
git commit
上增加-m <msg>
或--message=<msg>
参数,而单独写提交信息
不推荐
git commit -m "Fix login bug"
复制代码
推荐
angular的GitHub的Commit
Fix(filterFilter): fix filtering using an object expression when the …
…filter value is undefined
Fixes #10419
Closes #10424
复制代码
Commit Message分段写
Commit Message 分三个部分, header, body, footer. 其中,header 是必需的,body 和 footer 可以省略。 不管是哪一个部分,任何一行都不得超过100个字符,以免影响阅读性。
[<team>]<type>(<scope>): <subject>
<body>
<footer> 
复制代码
[FE]Fix(card): fix card edit, support to unuse item
在card修改里面,添加配置item未使用功能
复制代码
header
Header部分只有一行,包括四个字段:type(必需)、scope(可选)、team(可选)和subject(必需)。
type
用于说明 commit 的类别,只允许使用下面7个标识。
Add:新加功能
Fix:修补bug
Modify:移除无用代码
Remove:移除第三方模块或者移除文件
Update:更新第三方模块
Style: 格式(不影响代码运行的变动)
Chore:构建过程或辅助工具的变动
复制代码
scope
scope用于说明 commit 影响的范围,比如数据层、控制层、视图层等等,视项目不同而不同。
例如在shrezone,可以是file, card, image, short_video等。
如果你的修改影响了不止一个scope,你可以使用*代替。
team
当不同的team一起编写代码的时候,带team以区分工作区域
subject
subject是 commit 目的的简短描述,不超过50个字符。
其他注意事项:
以动词开头,使用第一人称现在时,比如change,而不是changed或changes
第一个字母小写
结尾不加句号(.)
复制代码
Body
Body 部分是对本次 commit 的详细描述,可以分成多行。
比如react的提交
Sync out another jsx transform test.
We added this test internally and it never got added here. We haven't broken it
with any transforms *yet* but it's still good to actually run all of our tests
here too.
复制代码
注意点:
使用第一人称现在时,比如使用change而不是changed或changes。
要和header之间有一个空行
应该说明代码变动的动机,以及与以前行为的对比。
复制代码
Footer
Footer 部分只用于以下两种情况:
不兼容变动
如果当前代码与上一个版本不兼容,则 Footer 部分以BREAKING CHANGE开头,后面是对变动的描述、以及变动理由和迁移方法。
关闭 Issue
如果当前 commit 针对某个issue,那么可以在 Footer 部分关闭这个 issue 。
Revert
一种特殊情况,如果当前 commit 用于撤销以前的 commit,则必须以revert:开头,后面跟着被撤销 Commit 的 Header。
revert: feat(pencil): add ‘graphiteWidth‘ option
This reverts commit 667ecc1654a317a13331b17617d973392f415f02
复制代码
最后
当然在很多时候,也不能每次都按照规范来写Commit Message,但是最起码每次重要的提交都能写,关键时候有用。
当然有人会用打tag的方式来表明重要节点,但是毕竟物尽其用,个有所长。
如果爱好使用工具的朋友也可以自行研究:
- commitizen 帮助写规范的message的命令行工具
- commitlint Lint 提交的message