原文链接: Git Commit Message 应该怎么写?
最近被搭档吐槽了,说我代码提交阐明写的太差。其实都不用他吐槽,我自己心里也十分清楚。究竟很多时候犯懒,都是直接一个 -m "fix"
就提交上去了。
这样做是十分欠好的,我也是自食恶果,深受其害。特别是检查历史提交记录时,想通过提交阐明来了解当时的功用变更,基本不可能,都得点进去看代码才行。
所以这两天看了一些如何写好提交阐明的资料,体系地学习了一下。尽管团队没有这方面的要求,可是想要前进,得对自己提更高的要求才行。
一般运用 git 提交代码的话,能够运用 -m
参数来指定提交阐明,比方:
$ git commit -m "hello world"
假如一行不行,能够只履行 git commit
,这样就会跳出文本编辑器来写多行:
$ git commit
Commit Message 格局
Commit Message 包含三个部分:Header,Body 和 Footer。
<Header>
<Body>
<Footer>
其间,Header 是必需的,Body 和 Footer 能够省掉。
Header
Header 部分只有一行,包含三个字段:type(必需)、scope(可选)、subject(必需)。
<type>(<scope>): <subject>
type
type 用于阐明 commit 的类别,详细的标识如下:
-
feat
:一个新的功用(feature); -
fix
:修正 bug; -
docs
:修正文档,比方 README.md、CHANGELOG.md 等; -
style
:修正代码的格局,不影响代码运转的变化,比方空格、格局化代码、补齐句末分号等等; -
refactor
:代码重构,没有新功用的增加以及 bug 修正的代码改动; -
perf
:优化代码以提高功用; -
test
:增加测验或优化改善现有的测验; -
build
:修正影响项目构建文件或外部依靠项,比方 npm、gulp、webpack、broccoli 等; -
ci
:修正 CI 配置文件和脚本; -
chore
:其他非 src 路径文件和测验文件的修正,比方 .gitignore、.editorconfig 等; -
revert
:代码回退;
scope
scope 用于阐明 commit 的影响范围,比方数据层、操控层、视图层等等,视项目不同而不同。
假如你的修正影响了不止一个 scope,就能够运用 *
替代。
subject
subject 是 commit 目的的简单描述,不超过 50 个字符,结束不需要句号。
Body
Body 部分是对本次 commit 的详细描述,能够分多行。
Body 部分应该阐明代码变化的动机,以及与曾经行为的对比。
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
Footer
Footer 部分主要用于两种状况:不兼容变化和处理 Issue。
不兼容变化
假如当时代码与上一个版本不兼容,则 Footer 部分以 BREAKING CHANGE:
最初,后边便是对变化的描述、以及变化理由和搬迁办法。
BREAKING CHANGE: Previously, $compileProvider.preAssignBindingsEnabled was set to true by default. This means bindings were pre-assigned in component constructors. In Angular 1.5+ the place to put the initialization logic relying on bindings being present is the controller $onInit method.
To migrate follow the example below:
Before:
```js
angular.module('myApp', [])
.component('myComponent', {
bindings: {value: '<'},
controller: function() {
this.doubleValue = this.value * 2;
}
});
```
After:
```js
angular.module('myApp', [])
.component('myComponent', {
bindings: {value: '<'},
controller: function() {
this.$onInit = function() {
this.doubleValue = this.value * 2;
};
};
this.doubleValue = this.value * 2;
}
});
```
Don't do this if you're writing a library, though, as you shouldn't change global configuration then.
处理 Issue
处理 Issue 分为两种状况,分别是相关 Issue 和关闭 Issue。
比方本次提交假如和某个 issue 有关系:
Issue #1, #2, #3
假如当时提交信息解决了某个 issue:
Close #1, #2, #3
Revert
还有一种特殊状况,假如当时 commit 用于吊销曾经的 commit,则有必要以 revert:
最初,后边跟着被吊销 commit 的 Header。
revert: feat(pencil): add 'graphiteWidth' option
This reverts commit 667ecc1654a317a13331b17617d973392f415f02.
Body 部分的格局是固定的,有必要写成 This reverts commit <hash>.
,其间 hash 是被吊销 commit 的 SHA 标识符。
假如当时 commit 与被吊销的 commit,在同一个发布(release)里面,那么它们都不会出现在 Change log 里面。假如两者在不同的发布,那么当时 commit,会出现在 Change log 的 Reverts 小标题下面。
最终来看一个比如,算是一个总结,至于详细内容仍是要根据实际状况来填写。
feat: 增加了共享功用
给每篇博文增加了共享功用
- 增加共享到微博功用
- 增加共享到微信功用
- 增加共享到朋友圈功用
Issue #1, #2
Close #1
插件引荐
有了这些规范,也知道怎么写了,可是不是会忧虑记不住呢?不要怕,有插件能够用,假如运用 VsCode 的话,能够安装一个叫 Commit Message Editor 的插件。
能够根据提示信息直接写:
也能够运用表单的方法,有选项能够挑选:
这样不只能够很方便地写提交阐明了,还能够使提交阐明愈加的规范。
以上便是本文的全部内容,假如觉得还不错的话欢迎点赞,转发和关注,感谢支持。
参考文章:
- /post/696054…
- mrseawave.github.io/blogs/artic…
引荐阅览:
- Git 分支管理策略