想推广下自己写的 maven 插件用来规范 git commit message

[Rugal]

背景

每个开发都有自己偏好的提交信息写法，比如

CRT-436 used constants as parameter names
BA2-295 - Put check for associate flow to view Calendar button
Switch back to applying boost rules by default; add

以上是我看到的几种例子。有的人喜欢在提交信息里加上工单号，有的人不想加；有的人喜欢用过去式，有的人喜欢用小写。这样的不统一导致审美的困难。

NPM 里有很多很方便的 commit linter 例如 commitlint. 通过配置文件和命令，能够统一提交时的消息规则，例如大小写，格式等等。

我希望能把消息格式检测流程也放在 maven 生命周期中,使得 CICD 的时候能一并检查到.
经过几天时间开发，本人初步完成了这个 Maven Plugin，目前已经发布到 Maven Repository.

基本用法

项目地址

加入插件

<plugin>
  <groupId>ga.rugal.maven</groupId>
  <artifactId>commitlinter-maven-plugin</artifactId>
  <version>THE-VERSION-YOU-LIKE</version>
</plugin>

添加配置

<configuration>
  <matchPattern>([\w\s]+-\d+:\s)(.*)</matchPattern>
  <failOnError>true</failOnError>
  <captureGroups>
    <captureGroup>
      <max>10</max>
      <min>2</min>
      <caseFormat>LOWERCASE</caseFormat>
    </captureGroup>
    <captureGroup>
      <max>20</max>
      <caseFormat>SENTENCECASE</caseFormat>
    </captureGroup>
  </captureGroups>
</configuration>

该配置下我们会将提交信息分为两组，第一组为工单信息，第二组为提交内容。

所以一个符合本配置的提交信息应该形如:

ABC-123: Lower case

试验一下

mvn commitlinter:validate

在本配置下，不匹配的提交会被拒绝

[rugal@ubuntu Almanac]> mvn commitlinter:validate
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Daily almanac for Programmer 0.1-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- commitlinter-maven-plugin:1.1:validate (default-cli) @ almanac ---
[INFO] Linting: [enable checkstyle]
[ERROR] Case format should be SENTENCECASE
[ERROR] Length should be no more than 10
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE

而匹配的提交则会通过。

[rugal@ubuntu Almanac]> mvn commitlinter:validate
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Daily almanac for Programmer 0.1-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- commitlinter-maven-plugin:1.1:validate (default-cli) @ almanac ---
[INFO] Linting: [ABC-123: Enable checkstyle]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.698 s
[INFO] Finished at: 2017-11-25T00:18:28-05:00
[INFO] Final Memory: 18M/175M
[INFO] ------------------------------------------------------------------------

这样，如果提交信息不符合规定的格式，CI 就会将其拒绝。这样便可以更好的统一提交信息啦。

欢迎大家参与该项目的开发，希望和大家互相学习。

[zjp]

妙啊
上个月看到公司一个公共项目，连着 30 多个信息只有"0"的 commit…脱口而出一句“哪个傻 b”

[Kilerd]

怎么看都觉得不是靠谱的方法啊。思路没错，但是 「我希望能把消息格式检测流程也放在 maven 生命周期中,使得 CICD 的时候能一并检查到.」 这么做的话。commit 已经上到 git 服务器了。你这时候说 CICD 检测不过，那么怎么办？

reset commit and then force push ?

正确的做法不应该是仍在 git pre commit hook 里面吗？ 直接拦截住 commit 的过程。

[aguesuka]

同意头上，应该仍在 git pre commit hook

[retanoj]

感觉 git hook 是比较合适的时间点

[hantsy]

@zjp 这种情况太多了。

[x66]

同意 2 楼，我们前后端项目放在同一个仓库，前端有 commitlint，如果不符合规范所有代码都无法提交，

[Rugal]

@Kilerd 谢谢指点.
首先应该是本地要 build 一遍,不通过就不应该 push.然后就算是 push 了,也是到你自己的 branch,CI 不通过的话就应该过相应的修改.修改完之后做 force push.
git pre commit hook 是好,这也是本插件之后可以努力的方向,可以把配置写到 hook 里面去.
但 hook 本身也有一定限制,需要每次都手动添加到本地配置等等.

[Rugal]

@zjp 哈 这种情况我倒是没见过,但我见过很多 format, remove space, remove space again 这种东西

[Rugal]

@x66 那么前后端不在一起的怎么办呢

[Kilerd]

@Rugal #7 等碰到严格一点的服务器，禁止 force push 的你就知道了什么叫做不可行

[lbyo]

@Kilerd #10 想问一下，这种情况下，rebase push 怎么操作

[Rugal]

@Kilerd 嗯 那是的

[Croce]

我们公司的代码就禁止 force push，提交分支到现在已经是一团乱麻了

[ZSeptember]

公共分支才要禁止 force push，自己 fork 的分支应该允许 force 的，不然不能 rebase 再 push。

[Rugal]

@ZSeptember 嗯 而且一般来说是先到自己的 repo 再去公共 repo,自己的 repo 怎么玩都没事

[Rugal]

@Croce 理论上应该先 fork, 然后自己的 repo 里玩
PR 完毕要合并之前 rebase squash 好, 在 merge 进公共仓库
这样子怎么样都没事.

[Rugal]

@zjp 欢迎推广,使用啊!! 正在写一个可以利用 git commit hook 的版本