Git提交代码规范 而且规范的Git提交历史，还可以直接生成项目发版的CHANGELOG（semantic-release）

Git提交代码规范 - 木之子梦之蝶 - 博客园 https://www.cnblogs.com/liumengdie/p/7885210.html



Commit message 的格式




Git 每次提交代码，都要写 Commit message（提交说明），否则就不允许提交。




用commit message最好是能有规范和工具的约束。




每次提交，Commit message 都包括三个部分：header，body 和 footer。




其中，header 是必需的，body 和 footer 可以省略。
不管是哪一个部分，任何一行都不得超过72个字符（或100个字符）。这是为了避免自动换行影响美观。
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>　
Header
Header部分只有一行，包括三个字段：type（必需）、scope（可选）和subject（必需）。




type
用于说明 commit 的类别，只允许使用下面7个标识。




feat：新功能（feature）




fix：修补bug




docs：文档（documentation）




style： 格式（不影响代码运行的变动）




refactor：重构（即不是新增功能，也不是修改bug的代码变动）




test：增加测试




chore：构建过程或辅助工具的变动




如果type为feat和fix，则该 commit 将肯定出现在 Change log 之中。其他情况（docs、chore、style、refactor、test）由你决定，要不要放入 Change log，建议是不要。




scope
scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。




例如在Angular，可以是$location, $browser, $compile, $rootScope, ngHref, ngClick, ngView等。




如果你的修改影响了不止一个scope，你可以使用*代替。




subject
subject是 commit 目的的简短描述，不超过50个字符。




其他注意事项：




以动词开头，使用第一人称现在时，比如change，而不是changed或changes




第一个字母小写




结尾不加句号（.）




Body
Body 部分是对本次 commit 的详细描述，可以分成多行。下面是一个范例。




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
　　




有两个注意点:




使用第一人称现在时，比如使用change而不是changed或changes。




永远别忘了第2行是空行




应该说明代码变动的动机，以及与以前行为的对比。




Footer
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 。




1
Closes #234
　　




Revert
还有一种特殊情况，如果当前 commit 用于撤销以前的 commit，则必须以revert:开头，后面跟着被撤销 Commit 的 Header。




revert: feat(pencil): add 'graphiteWidth' option
 
This reverts commit 667ecc1654a317a13331b17617d973392f415f02.
　　




Body部分的格式是固定的，必须写成This reverts commit &lt;hash>.，




其中的hash是被撤销 commit 的 SHA 标识符。




如果当前 commit 与被撤销的 commit，在同一个发布（release）里面，




那么它们都不会出现在 Change log 里面。




如果两者在不同的发布，那么当前 commit，会出现在 Change log 的Reverts小标题下面。




 




Git提交规范 - 知乎 https://zhuanlan.zhihu.com/p/67804026




规范的作用




大多数情况下，看提交历史的人跟提交代码的人都不是同一个人，当别人阅读你的提交历史时，他很可能是不知道具体代码细节的，你如何在最短的时间内让他一眼知道每次提交的意义：




    

  • 每次提交影响的具体范围？
    • 

  • 这个bug在哪次提交中被修复了？
    • 

  • 这个新功能是在哪次提交中增加的？
    • 

  • 修改是否向下兼容？
    • 

  • 是否回滚了代码？
    • 

  • 是否只是修改了文档、调整了代码格式？
    • 

  • 是否修改了测试、是否进行了重构？
    • 

  • 是否对代码进行了性能优化？
    • 





这些都是提交规范的作用。




代码复查/审查




良好的Git提交日志非常重要，最明显的一点是，它让整个Git提交历史的阅读变得非常轻松：




 




 


 


AngularJS commits


一眼看上去，就知道每个提交是做了什么，是加了新功能，还是修改了bug，是维护了文档，还是调整了单元测试，都一目了然。


生成CHANGELOG


而且规范的Git提交历史，还可以直接生成项目发版的CHANGELOG（semantic-release）：




 




 




AngularJS CHANGELOG

AngularJS的开发指南中已经对Git的提交日志做了明确规范，这种规范几乎适用于所有项目，本文搬运过来，粗糙翻译，与君共享。


规范细则


对于Git的提交日志，我们有非常明确而详细的提交规范。这将有助于我们在查看项目历史时，更容易明确每一次提交的内容。另一方面，我们还直接使用了Git提交日志来生成AngularJS的变更日志。


Git的提交日志可以通过常用的Git工作流或向导工具(Commitizen)来生成。如果你选择使用Commitizen，那只需要在Git暂存修改后，执行“yarn run commit”命令即可。


提交消息格式


每个提交消息都由一个标题、一个正文和一个页脚组成。而标题又具有特殊格式，包括修改类型、影响范围和内容主题：




修改类型(影响范围): 标题
<--空行-->
[正文]
<--空行-->
[页脚]




标题是强制性的，但标题的范围是可选的。


提交消息的任何一行都不能超过100个字符！这是为了让消息在GitHub以及各种Git工具中都更容易阅读。


修改类型


每个类型值都表示了不同的含义，类型值必须是以下的其中一个：


    

  • feat：提交新功能
    • 

  • fix：修复了bug
    • 

  • docs：只修改了文档
    • 

  • style：调整代码格式，未修改代码逻辑（比如修改空格、格式化、缺少分号等）
    • 

  • refactor：代码重构，既没修复bug也没有添加新功能
    • 

  • perf：性能优化，提高性能的代码更改
    • 

  • test：添加或修改代码测试
    • 

  • chore：对构建流程或辅助工具和依赖库（如文档生成等）的更改
    • 



代码回滚


代码回滚比较特殊，如果本次提交是为了恢复到之前的某个提交，那提交消息应该以“revert:”开头，后跟要恢复到的那个提交的标题。然后在消息正文中，应该写上“This reverts commit <hash>”，其中“<hash>”是要还原的那个提交的SHA值。


影响范围


范围不是固定值，它可以是你提交代码实际影响到的任何内容。例如$location、$browser、$compile、$rootScope、ngHref、ngClick、ngView等，唯一需要注意的是它必须足够简短。


当修改影响多个范围时，也可以使用“*”。


标题


标题是对变更的简明描述：


    

  • 使用祈使句，现在时态：是“change”不是“changed”也不是“changes”
    • 

  • 不要大写首字母
    • 

  • 结尾不要使用句号
    • 



正文


正文是对标题的补充，但它不是必须的。和标题一样，它也要求使用祈使句且现在时态，正文应该包含更详细的信息，如代码修改的动机，与修改前的代码对比等。


页脚


任何Breaking Changes（破坏性变更，不向下兼容）都应该在页脚中进行说明，它经常也用来引用本次提交解决的GitHub Issue。


Breaking Changes应该以“BREAKING CHANGE:”开头，然后紧跟一个空格或两个换行符，其他要求与前面一致。


最后说一句


人生苦短，请遵守规范。


参考链接














编辑于 2019-06-02


 




别乱提交代码了，看下大厂 Git 提交规范是怎么做的！ - 知乎 https://zhuanlan.zhihu.com/p/100773495

如何规范地提交 Git Commit Message - 知乎 https://zhuanlan.zhihu.com/p/162688604


https://zhuanlan.zhihu.com/p/182553920


如何规范你的Git commit？ - 知乎 https://zhuanlan.zhihu.com/p/182553920










            

            
posted @ 
2019-03-08 21:40 
papering 
阅读(1650) 
评论(0) 
编辑 
收藏 
举报