目标 生成 CHANGELOG.md识别不重要的提交在浏览 Git 历史时提供更多信息格式化提交信息 恢复(Revert)信息头部
- 必需<type>- 必需<scope>- <subject>文本信息主体信息尾部
- 重大更改(Breaking changes)- 引用讨论(Referencing issues)
目标
能够通过脚本生成 CHANGELOG.md能让 git bisect 过程忽略不重要的提交在浏览历史时提供更好的信息
生成 CHANGELOG.md
我们在 changeling 里使用这三个标志: new features, bug fixes, breaking changes. 在做一个发行版的时候,这个列表可以通过脚本来生成,通过关联这些相关的提交。 自然,你可以在实际发行之前编辑这些变更日志,但是这样子可以很容易的生成骨架。
列出自最近一次发行以来所有的主体(提交信息第一行)
>> git log <last tag> HEAD —pretty=format:%s
在本次发行内的新功能
>> git log <last release> HEAD —grep feature
识别不重要的提交
通常有很多的Formatting changes(adding/removing spaces/empty lines, indentation), missing semicolons, comments.所以当你查找一些变更的时候,你可以忽略这些提交 - 这些提交里面没有业务逻辑变更。
当二分查找的时候,你可以忽视这些提交通过键入以下命令:
>> git bisect skip $(git rev-list —grep irrelevant <good place> HEAD)
在浏览历史时提供更多信息
这将会增加一种“context”信息 看这些信息(通过查看最近的 angularjs 的提交信息)
Fix small typo in docs widget (tutorial instructions)Fix test for scenario.Application - should remove old iframedocs - various doc fixesdocs - stripping extra new linesReplaced double line break with single when text is fetched from GoogleAdded support for properties in documentation
所有这些信息都尝试去表明更改的位置,但是它们没有使用公共的规范 再看看这些信息:
fix comment strippingfixing broken linksBit of refactoringCheck whether links do exist and throw exceptionFix sitemap include (to work on case sensitive linux)
你能猜出这里面到底装了些什么?这些信息缺乏重点。 也许还有这些代码:docs, docs-parser, compiler, scenario-runner, ... 我知道,你可以通过查看哪些文件被改变来确定这个提交到底做了什么,但是这样子太麻烦了。 当查看 git 历史信息的时候我们可以看到大家都在努力保持一致,但是缺少一个公共规范。
提交信息的格式化
<type>(<scope>):<subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
提交信息的任意一行都不能超过100个英文字符!这个能让信息在 github 上和 git 工具里更容易查看。
恢复
如果提交是用于恢复一个更早的提交,这个头部应该以“revert:”开始,接下来是被恢复提交的头部,在主体内应该写“This reverts commit <hash>.”,hash 的位置就是被恢复提交的 sha 值
信息头部
信息头部应该是包含改变的一条单行简要描述,包括一个类型,一个可选的范围和一个主题
必需的<type> 这是用于说明提交的类型,下列是7个标志。
feat: 新功能fix : 修补bugdocs: 文档style: 格式化,缺少分号等refactortest: 增加缺少的测试chore 维护
必需的<scope> 范围可以是任何制定的提交更改的地方。例如 $location, $browser, $compile, $rootScope, ngHref, ngClick, ngView等等 <subject>文本 这是变更的简单描述
以动词开头,使用第一人称现在时,比如change,而不是changed或changes第一个字母小写结尾不加句号
信息主体
这部分是对本次提交的详细描述,可以分成多行
使用第一人称现在时,比如使用 change 而不是 changed 或者 changes。说明代码变更的冬季,以及和以前代码的对比
信息尾部
只有两种情况: 不兼容变动 所有不兼容变动应该被列为不兼容变动块放在信息尾部,应该以“BREAKING CHANGE:”开始,后面是对变动的描述,以及变动的动机和迁移方法 引用讨论 如果当前提交是针对某个讨论,那么可以在尾部关闭这个讨论 Closes #234 或者同时关闭多个讨论 Closes #123, #245, #992