是时候规范一下我们的git commit了

Angular 规范使用代码 commit 的方式

概要说明:Git 每次提交代码都要写 commit message (提交说明),否则就不允许提交。但是, 一般来说,commit message 应该清晰明了,说明本次提交的目的,可就是有一些人写了些乱七八糟的东西上来。目前社区有很多种 commit message 方案,其中 Angular规范是目前使用最广的写法,比较合理和系统化,并且有配套的工具。前前端框架 Angular.js 采用的就是该规范。

1. 使用 Angular commit Standard 的作用

- 方便查看每次提交版本更新内容: `git log <last tag> HEAD --pretty=format:%s`
- 方便的查找某个关键技术处在哪个版本: `git log <last release> HEAD --grep feature`
- 可以自动生成 `CHANGELOG`
- 可读性好,方便做 `code revieing`
- 方便 `git blame` 跟踪工程历史,追究模块责任,提高代码质量

2. 提交格式

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

例如:
feat(route, controller, service): add users module

we add users entity for mutil method apis
  • 其中 Header 一行是必须的,BodyFooter 是可选的。
  • 建议提交的说明部分不一行要太长,影响单行显示效果

3. 提交格式详细说明

  • Header: 只有一行,包括三个字段:type(必需)、scope(可选)和 subject(必需)。
    • type: 用于说明 commit 的类别,只允许使用下面7个标识。如果type为 feat和fix,则该 commit 将肯定出现在 CHANGELOG 中。其他情况(docs、chore、style、refactor、test)由你决定,要不要放入 CHANGELOG,建议不要。
    feat:新功能(feature)
    fix:修补bug
    docs:文档(documentation)
    style: 格式(不影响代码运行的变动)
    refactor:重构(即不是新增功能,也不是修改bug的代码变动)
    test:增加测试
    chore:构建过程或辅助工具的变动
    
    • scope: 用于说明 commit 影响的范围,比如数据层、控制层、视图层等等,如果你的修改影响了不止一个 scope,可以使用*代替。。
    • subject: subjectcommit 目的的简短描述,不超过50个字符。
    • 以动词开头,使用第一人称现在时,比如 change,而不是changed或changes
    • 第一个字母小写
    • 结尾不加句号(.)
  • Body: 对本次 commit 的详细描述,可以分成多行。下面有一个范例。
    • 使用第一人称现在时,比如使用 change 而不是 changed或changes
    • 永远别忘了第2行是空行。
    • 应该说明代码变动的动机,以及与以前行为的对比。
    More detailed explanatory text, if necessary.  
        Wrap it to about 72 characters or so. 
    Further paragraphs come after blank lines.
    - Bullet points are okay, too
    - Use a hanging indent
    
  • Footer:
    • 不兼容变动: 如果当前代码与上一个版本不兼容,则 Footer 部分以 BREAKING CHANGE 开头,后面是对变动的描述、以及变动理由和迁移方法。
      BREAKING CHANGE: isolate scope bindings definition has changed.
      To migrate the code follow the example below:
      Before:
      scope: {
          myAttr: 'attribute',
      }
      After:
      scope: {
          myAttr: '@',
      }
      The removed `inject` wasn't generaly useful for directives 
      so there should be no code using it.
      
    • 关闭issue: 如果当前 commit 针对某个 issue ,那么可以在 Footer 部分关闭这个 issue
      Closes #234
      Closes #234,#231,#424
      

4. 使用工具提交代码

  • 可以使用典型的 gitflow 或通过使用CLI向导 commitizen 来添加提交消息格式。
  • 安装CLI工具并使其支持 Angular 规范
    npm install -g commitizen
    commitizen init cz-conventional-changelog --save --save-exact
    
  • 后续所有的 git commit 都用 git cz 代替。

5. 如何生成 CHANGELOG

  • 如果你的所有 commit 都符合 Angular 格式,那么发布新版本时,CHANGELOG 就可以用 conventional-changelog 脚本自动生成。
  • 生成的文档包括以下三个部分: New features, Bug fixes, Breaking changes
  • 每个部分都会罗列相关的 commit ,并且有指向这些 commit 的链接。生成的文档允许手动修改,所以发布前,你还可以添加其他内容。
  • 生成 CHANGELOG 请依次执行下面的命令
    npm install -g conventional-changelog
    cd my-project
    conventional-changelog -p angular -i CHANGELOG.md -w
    

6. 参考

7. 相关问题解答

  1. 妹妹:不用工具,我们团队手动书写的提交消息乱七八糟的怎么办?

    哥哥:那你装个 Commitizen 不行? 或者使用 validate-commit-msg 包校验提交是否符合规范,类似于 pre-commit 拦截。

  2. 妹妹:每次一个版本发布生成 CHANGELOG 的命令好长,我记不住?

    哥哥:你可以把它写进 Ppackage.json 文件的 script 中啊。像我这样以后就只要运行 npm run changlog 生成 CHANGELOG: "changelog": "conventional-changelog -p angular -i CHANGELOG.md -w"

  3. 妹妹:提问?

    哥哥:生动举例的回答。

©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容