这是一个创建于 2140 天前的主题，其中的信息可能已经有所发展或是发生改变。
背景
每个开发都有自己偏好的提交信息写法，比如
CRT-436 used constants as parameter names
BA2-295 - Put check for associate flow to view Calendar button
Switch back to applyin 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 就会将其拒绝。这样便可以更好的统一提交信息啦。
欢迎大家参与该项目的开发，希望和大家互相学习。
 | 1 zjp 2020-02-21 13:27:01 +08:00 via Android 妙啊 上个月看到公司一个公共项目，连着 30 多个信息只有"0"的 commit…脱口而出一句“哪个傻 b” |
 | 2 Kilerd 2020-02-21 13:36:02 +08:00  2 怎么看都觉得不是靠谱的方法啊。思路没错，但是 「我希望能把消息格式检测流程也放在 maven 生命周期中,使得 CICD 的时候能一并检查到.」 这么做的话。commit 已经上到 git 服务器了。你这时候说 CICD 检测不过，那么怎么办？ reset commit and then force push ? 正确的做法不应该是仍在 git pre commit hook 里面吗？ 直接拦截住 commit 的过程。 |
 | 3 aguesuka 2020-02-21 13:47:03 +08:00 同意头上，应该仍在 git pre commit hook |
 | 4 retanoj 2020-02-21 15:22:24 +08:00 感觉 git hook 是比较合适的时间点 |
 | 6 x66 2020-02-21 16:54:10 +08:00 同意 2 楼，我们前后端项目放在同一个仓库，前端有 commitlint，如果不符合规范所有代码都无法提交， |
 | 7 Rugal OP @Kilerd 谢谢指点. 首先应该是本地要 build 一遍,不通过就不应该 push.然后就算是 push 了,也是到你自己的 branch,CI 不通过的话就应该过相应的修改.修改完之后做 force push. git pre commit hook 是好,这也是本插件之后可以努力的方向,可以把配置写到 hook 里面去. 但 hook 本身也有一定限制,需要每次都手动添加到本地配置等等. |
| 8 Rugal OP @zjp 哈 这种情况我倒是没见过,但我见过很多 format, remove space, remove space again 这种东西 |
 | 13 Croce 2020-02-22 18:44:53 +08:00 我们公司的代码就禁止 force push，提交分支到现在已经是一团乱麻了 |
 | 14 looplj 2020-02-23 11:18:17 +08:00 公共分支才要禁止 force push，自己 fork 的分支应该允许 force 的，不然不能 rebase 再 push。 |
| 15 Rugal OP @ZSeptember 嗯 而且一般来说是先到自己的 repo 再去公共 repo,自己的 repo 怎么玩都没事 |
| 16 Rugal OP |
Slect Language