3.6 KiB
提交规范 前面我们已经统一代码规范，并且在提交代码时进行强约束来保证仓库代码质量。多人协作的项目中，在提交代码这个环节，也存在一种情况：不能保证每个人对提交信息的准确描述，因此会出现提交信息紊乱、风格不一致的情况。 如果 git commit 的描述信息精准，在后期维护和 Bug 处理时会变得有据可查，项目开发周期内还可以根据规范的提交信息快速生成开发日志，从而方便我们追踪项目和把控进度。 这里，我们使用社区最流行、最知名、最受认可的 Angular 团队提交规范。
commit message 格式规范 commit message 由 Header、Body、Footer 组成。
复制代码 Header Header 部分包括三个字段 type（必需）、scope（可选）和 subject（必需）。 (): 复制代码 type type 用于说明 commit 的提交类型（必须是以下几种之一）。值描述feat新增一个功能fix修复一个 Bugdocs文档变更style代码格式（不影响功能，例如空格、分号等格式修正）refactor代码重构perf改善性能test测试build变更项目构建或外部依赖（例如 scopes: webpack、gulp、npm 等）ci更改持续集成软件的配置文件和 package 中的 scripts 命令，例如 scopes: Travis, Circle 等chore变更构建流程或辅助工具revert代码回退 scope scope 用于指定本次 commit 影响的范围。scope 依据项目而定，例如在业务项目中可以依据菜单或者功能模块划分，如果是组件库开发，则可以依据组件划分。（scope 可省略） subject subject 是本次 commit 的简洁描述，长度约定在 50 个字符以内，通常遵循以下几个规范：
用动词开头，第一人称现在时表述，例如：change 代替 changed 或 changes 第一个字母小写 结尾不加句号（.）
Body body 是对本次 commit 的详细描述，可以分成多行。（body 可省略） 跟 subject 类似，用动词开头，body 应该说明修改的原因和更改前后的行为对比。 Footer 如果本次提交的代码是突破性的变更或关闭缺陷，则 Footer 必需，否则可以省略。
突破性的变更 当前代码与上一个版本有突破性改变，则 Footer 以 BREAKING CHANGE 开头，后面是对变动的描述、以及变动的理由。
关闭缺陷 如果当前提交是针对特定的 issue，那么可以在 Footer 部分填写需要关闭的单个 issue 或一系列 issues。
参考例子
feat feat(browser): onUrlChange event (popstate/hashchange/polling)
Added new event to browser:
- forward popstate event if available
- forward hashchange event if popstate not available
- do polling when neither popstate nor hashchange available
Breaks $browser.onHashChange, which was removed (use onUrlChange instead) 复制代码
fix fix(compile): couple of unit tests for IE9
Older IEs serialize html uppercased, but IE9 does not... Would be better to expect case insensitive, unfortunately jasmine does not allow to user regexps for throw expectations.
Closes #392 Breaks foo.bar api, foo.baz should be used instead 复制代码
style style(location): add couple of missing semi colons 复制代码
chore chore(release): v3.4.2 复制代码
规范 commit message 的好处
首行就是简洁实用的关键信息，方便在 git history 中快速浏览。 具有更加详细的 body 和 footer，可以清晰的看出某次提交的目的和影响。 可以通过 type 过滤出想要查找的信息，也可以通过关键字快速查找相关提交。 可以直接从 commit 生成 change log。