git提交规范

,

一直是 ESLint 的忠实用户，深知规范的重要性。然而，在新项目交接中，我被 Git Commit 规范逼疯了。才意识到自己的疏忽，于是便有了一探究竟的想法。分享自开发头条

一、为什么需要规范？

  无规矩不成方圆，编程也一样。
  如果你有一个项目，从始至终都是自己写，那么你想怎么写都可以，没有人可以干预你。可是如果在团队协作中，大家都张扬个性，那么代码将会是一团糟，好好的项目就被糟践了。不管是开发还是日后维护，都将是灾难。
  这时候，有人提出了何不统一标准，大家都按照这个标准来。于是ESLint，JSHint等代码工具如雨后春笋般涌现，成为了项目构建的必备良品。
   Git Commit规范可能并没有那么夸张，但如果你在版本回退的时候看到一大段糟心的Commit，恐怕会懊恼不已吧。所以，严格遵守规范，利人利己。

二、具体规则

先来看看公式;<type>(<scope>): <subject>

  1. type:用于说明commit的类别，只允许使用下面7个标识。
    • feat:新功能（feature）
    • fix：修补bug
    • docs：文档（documentation）
    • style： 格式（不影响代码运行的变动）
    • refactor：重构（即不是新增功能，也不是修改bug的代码变动）
    • test：增加测试
    • chore：构建过程或辅助工具的变动
  2. scope:用于说明commit影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。
  3. subject:是commit目的的简短描述，不超过50个字符。
    • 以动词开头，使用第一人称现在时，比如change，而不是changed或changes
    • 第一个字母小写
    • 结尾不加句号（.）

三、异常处理

  我们先来看看这个异常提醒：INVALID COMMIT MSG: does not match “(): “ ! jartto:fix bug 这里之所以报出这个警告，是因为我的提交出现了两个问题：其一，使用了规范外的关键字；其二，很细节的问题，jartto：后少了空格；
这时候我才回忆起来，当时提交一直失败，情急之下直接强制提交，所以以后的提交都会抱出这个异常。大致意思就是：你的之前的 Commit 不合格～你的之前的 Commit 不合格～你的之前的 Commit 不合格
这时候就很烦了，我们只能去将之前的错误修正，那么如何操作呢？

四、如何修改之前的 commit 信息？

其实并不复杂，我们只需要这样做:

  1. 将当前分支无关的工作状态进行暂存 git stash
  2. 将HEAD移动到需要修改的commit上 git rebase 9633cf0919^ —interactive
  3. 找到需要修改的commit,将首行的pick改成edit
  4. 开始着手解决你的bug
  5. git add将改动文件添加到暂存
  6. git commit –amend追加改动到提交
  7. git rebase –continue移动HEAD回最新的commit
  8. 恢复之前的工作状态 git stash pop
    大功告成，是不是想把整个 Commit 都修改一遍，逃～

五、Commit 规范的作用

  1. 提供更多的信息，方便排查与回退；
  2. 过滤关键字，迅速定位；
  3. 方便生成文档；

七、总结

  看完文章，你还会如此放荡不羁吗？你还会随心所欲的编写Commit吗？你还会如此git commit -m “hello jartto”提交吗？答案是否定的，因为使用了钩子函数，你没有机会了，否则将是无穷无尽的恢复Commit。这倒可以养成良好的提交习惯，🙈～