代码提交那点事

现在，代码的版本管理大多都在使用 git，常用的一些代码托管平台有：Github、码云、Gitlab 等，不管用的哪个平台，我们经常会做提交代码的操作，但很容易忽视 commit message 的写法。

在一些工具中进行代码提交，提交信息是必填的，正因为是必填，就会出现很多随意的内容，例如：ok、update、test 等，这些毫无意义的信息内容会给后续工作带来很多麻烦。

所以，春节后上班第一件事就是在团队内强调提交信息的重要性，并制定统一规范。很多时候做不好，不是能力问题，而是态度问题。

在提交信息的规范上可以按照下面三个方面来做：

1、规范信息的写法；

2、提交信息的合并；

3、提交和任务关联。

规范信息的写法

commit message 通常包括两个部分：header、body ，如下：

1
2
3

<type>: <subject>   //冒号使用西文
//空一行
<body>

header 部分只有一行，包括两个字段：type（必须）和 subject（必须），type 和 subject 之间使用西文冒号和一个空格隔开。

type

用于说明 commit 的类别，只允许使用下面 3 个类别。类别不宜弄的太多，太多了开发人员在提交代码时会带来负担。下面这三个类别我认为几乎可以包含所有情况了：

feat：新功能（feature）
fixed：修复 bug
refactor：重构（即不是新增功能，也不是修改 bug 的代码修改）

subject

提交信息的标题，一句话总结提交的信息，尽量做到既简洁，又详细。

body（非必填）

body 部分是对本次 commit 的详细描述，可以分成多行，body 和 header 中间空一行。body 为非必填内容，如果 subject 中能说明白了，body 就可以空着。

如果你觉得一次 commit 的内容中包含下面一些情况，就可以在 body 中写明：

有相关联影响点的；
内容相对较多，subject 不能完全描述的；
提交内容包含特殊的意图。

提交合并

有了标准的规范后，提交的信息统一了、可读性更强，但有时在开发一个特性或修改一个 Bug 时，会 commit 很多次代码，这些提交目的其实是一个，如果能将这些 commit 记录合并起来，整体的提交信息记录就更加清晰。

将多个 commit 提交进行合并，需要用到 git 的 rebase 功能，下面进行一个简单的演示来看看 rebase 怎么使用：

1、在 gitlab 上创建一个示例项目 rebase_test；

2、将项目拉到本地，添加 README.md 文件，并推送到 gitlab ；

3、分三次修改 README.md 文件，进行三次 commit ，使用 git log 查看看提交记录如下：

4、将提交 push 到 gitlab ，在 gtilab 中显示如下：

5、现在要将这三次提交合并为一次，在 git 命令行执行：

1	git rebase -i 740aa70a

-i ：代表交互式操作；
740aa70a ：表示第一个提交的 commit id，取前几位就行。

6、按下图红框部分进行内容的修改，然后保存：

7、将三次修改的提交信息进行合并：

8、使用 git log 看提交信息的记录，会发现已经进行了合并：

和任务关联

在 git 中的每次提交，都是跟具体的任务相关，正常的迭代任务、Bug 任务等，如果能将任务和代码提交记录进行关联，对于后续的问题排查和查找修改记录会有很大帮助。

起初的想法是将任务的编号写到提交信息的 header 部分：

1
2
3

<type>: <taskNumber> <subject> 
//空一行
<body>

后来发现在 pingcode 的应用市场中有一个 Gitlab 应用，可以到达提交和任务关联的目的。恰好，我们团队也正在使用 pingcode 。

Gialab 应用的介绍是这样的：

GitLab 是由 GitLab Inc.开发的一款基于 Git 的完全集成的软件开发平台。GitLab在国内最广为人知的功能当属代码托管，这源于其基于Ruby on Rails的开源项目属性。GitLab App是由PingCode Labs开发的一款工具，它可以将GitLab的Commit、Branch、Merge Request关联到 PingCode 的工作项中。

详细的配置可以参考：

https://apps.pingcode.com/gitlab/configuration

最终任务关联后的效果如下：