V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Rugal
V2EX  ›  Java

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

  •  
  •   Rugal · 2020-02-21 13:13:13 +08:00 · 3071 次点击
    这是一个创建于 1497 天前的主题,其中的信息可能已经有所发展或是发生改变。

    背景

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

    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 就会将其拒绝。这样便可以更好的统一提交信息啦。

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

    17 条回复    2020-03-01 08:56:54 +08:00
    zjp
        1
    zjp  
       2020-02-21 13:27:01 +08:00 via Android
    妙啊
    上个月看到公司一个公共项目,连着 30 多个信息只有"0"的 commit…脱口而出一句“哪个傻 b”
    Kilerd
        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 的过程。
    aguesuka
        3
    aguesuka  
       2020-02-21 13:47:03 +08:00
    同意头上,应该仍在 git pre commit hook
    retanoj
        4
    retanoj  
       2020-02-21 15:22:24 +08:00
    感觉 git hook 是比较合适的时间点
    hantsy
        5
    hantsy  
       2020-02-21 15:27:51 +08:00
    @zjp 这种情况太多了。
    x66
        6
    x66  
       2020-02-21 16:54:10 +08:00
    同意 2 楼,我们前后端项目放在同一个仓库,前端有 commitlint,如果不符合规范所有代码都无法提交,
    Rugal
        7
    Rugal  
    OP
       2020-02-21 22:20:34 +08:00
    @Kilerd 谢谢指点.
    首先应该是本地要 build 一遍,不通过就不应该 push.然后就算是 push 了,也是到你自己的 branch,CI 不通过的话就应该过相应的修改.修改完之后做 force push.
    git pre commit hook 是好,这也是本插件之后可以努力的方向,可以把配置写到 hook 里面去.
    但 hook 本身也有一定限制,需要每次都手动添加到本地配置等等.
    Rugal
        8
    Rugal  
    OP
       2020-02-21 22:21:04 +08:00
    @zjp 哈 这种情况我倒是没见过,但我见过很多 format, remove space, remove space again 这种东西
    Rugal
        9
    Rugal  
    OP
       2020-02-21 22:21:23 +08:00
    @x66 那么前后端不在一起的怎么办呢
    Kilerd
        10
    Kilerd  
       2020-02-21 22:44:56 +08:00
    @Rugal #7 等碰到严格一点的服务器,禁止 force push 的你就知道了什么叫做不可行
    lbyo
        11
    lbyo  
       2020-02-21 22:55:22 +08:00
    @Kilerd #10 想问一下,这种情况下,rebase push 怎么操作
    Rugal
        12
    Rugal  
    OP
       2020-02-22 00:04:49 +08:00
    @Kilerd 嗯 那是的
    Croce
        13
    Croce  
       2020-02-22 18:44:53 +08:00
    我们公司的代码就禁止 force push,提交分支到现在已经是一团乱麻了
    ZSeptember
        14
    ZSeptember  
       2020-02-23 11:18:17 +08:00
    公共分支才要禁止 force push,自己 fork 的分支应该允许 force 的,不然不能 rebase 再 push。
    Rugal
        15
    Rugal  
    OP
       2020-02-29 05:15:51 +08:00
    @ZSeptember 嗯 而且一般来说是先到自己的 repo 再去公共 repo,自己的 repo 怎么玩都没事
    Rugal
        16
    Rugal  
    OP
       2020-02-29 05:16:56 +08:00
    @Croce 理论上应该先 fork, 然后自己的 repo 里玩
    PR 完毕要合并之前 rebase squash 好, 在 merge 进公共仓库
    这样子怎么样都没事.
    Rugal
        17
    Rugal  
    OP
       2020-03-01 08:56:54 +08:00
    @zjp 欢迎推广,使用啊!! 正在写一个可以利用 git commit hook 的版本
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2558 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 15:57 · PVG 23:57 · LAX 08:57 · JFK 11:57
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.