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

2020-02-21 13:13:13 +08:00
 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 就会将其拒绝。这样便可以更好的统一提交信息啦。

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

3253 次点击
所在节点    Java
17 条回复
zjp
2020-02-21 13:27:01 +08:00
妙啊
上个月看到公司一个公共项目,连着 30 多个信息只有"0"的 commit…脱口而出一句“哪个傻 b”
Kilerd
2020-02-21 13:36:02 +08:00
怎么看都觉得不是靠谱的方法啊。思路没错,但是 「我希望能把消息格式检测流程也放在 maven 生命周期中,使得 CICD 的时候能一并检查到.」 这么做的话。commit 已经上到 git 服务器了。你这时候说 CICD 检测不过,那么怎么办?

reset commit and then force push ?

正确的做法不应该是仍在 git pre commit hook 里面吗? 直接拦截住 commit 的过程。
aguesuka
2020-02-21 13:47:03 +08:00
同意头上,应该仍在 git pre commit hook
retanoj
2020-02-21 15:22:24 +08:00
感觉 git hook 是比较合适的时间点
hantsy
2020-02-21 15:27:51 +08:00
@zjp 这种情况太多了。
x66
2020-02-21 16:54:10 +08:00
同意 2 楼,我们前后端项目放在同一个仓库,前端有 commitlint,如果不符合规范所有代码都无法提交,
Rugal
2020-02-21 22:20:34 +08:00
@Kilerd 谢谢指点.
首先应该是本地要 build 一遍,不通过就不应该 push.然后就算是 push 了,也是到你自己的 branch,CI 不通过的话就应该过相应的修改.修改完之后做 force push.
git pre commit hook 是好,这也是本插件之后可以努力的方向,可以把配置写到 hook 里面去.
但 hook 本身也有一定限制,需要每次都手动添加到本地配置等等.
Rugal
2020-02-21 22:21:04 +08:00
@zjp 哈 这种情况我倒是没见过,但我见过很多 format, remove space, remove space again 这种东西
Rugal
2020-02-21 22:21:23 +08:00
@x66 那么前后端不在一起的怎么办呢
Kilerd
2020-02-21 22:44:56 +08:00
@Rugal #7 等碰到严格一点的服务器,禁止 force push 的你就知道了什么叫做不可行
lbyo
2020-02-21 22:55:22 +08:00
@Kilerd #10 想问一下,这种情况下,rebase push 怎么操作
Rugal
2020-02-22 00:04:49 +08:00
@Kilerd 嗯 那是的
Croce
2020-02-22 18:44:53 +08:00
我们公司的代码就禁止 force push,提交分支到现在已经是一团乱麻了
ZSeptember
2020-02-23 11:18:17 +08:00
公共分支才要禁止 force push,自己 fork 的分支应该允许 force 的,不然不能 rebase 再 push。
Rugal
2020-02-29 05:15:51 +08:00
@ZSeptember 嗯 而且一般来说是先到自己的 repo 再去公共 repo,自己的 repo 怎么玩都没事
Rugal
2020-02-29 05:16:56 +08:00
@Croce 理论上应该先 fork, 然后自己的 repo 里玩
PR 完毕要合并之前 rebase squash 好, 在 merge 进公共仓库
这样子怎么样都没事.
Rugal
2020-03-01 08:56:54 +08:00
@zjp 欢迎推广,使用啊!! 正在写一个可以利用 git commit hook 的版本

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/646333

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX