提交准则
提交问题
提交问题前，请搜索问题追踪器，可能你的问题已经存在，经过讨论可能会有解决的方案并且通知你。
我们希望尽快解决所有问题，但是在修复错误之前，我们需要重现并确认它。为了重现错误，我们将系统地要求你使用 http://plnkr.co 提供最少的重现方案。拥有可复制的实时场景，可以为我们提供大量重要信息，而不会像其他问题来回回问你：
- 使用 Angular 版本
- 第三方库及其版本
- 最重要的是一个失败的用例
使用 http://plnkr.co 的最小复制方案可以使我们快速确认错误（或指出编码问题）以及确认我们正在解决正确的问题。如果使用 plunker 并不是解决问题的合适方法（例如，与我们的 npm 打包有关的问题），请创建一个独立的 git 存储库来演示该问题。
我们将坚持使用最小的复制方案，以节省维护人员的时间，并最终能够修复更多的错误。有趣的是，根据我们的经验，用户经常会在准备少量代码的同时发现自己的编码问题。我们了解，有时可能很难从较大的代码库中提取代码的基本要点，但是我们确实需要隔离问题，然后才能对其进行修复。
不好的是，如果没有最少的复制，我们将无法调查/修复错误，因此，如果我们没有收到您的回音，我们将解决一个问题，该信息没有足够的复制信息。
您可以填写我们的新的 问题模板 来提交新问题。
提交消息准则
对于如何格式化 git commit 消息，我们有非常精确的规则。这会导致更具可读性的消息，在查看项目历史记录时易于遵循。而且，我们使用 git commit 消息生成 Angular 更改日志。
提交消息的格式
每个提交消息都包含一个标题，一个正文和一个页脚。标头具有一种特殊的格式，其中包括类型，范围和主题：
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
标头是必需的，标头的范围是可选的。
提交消息的任何一行都不能超过100个字符！这使得该消息在 GitHub 以及各种 git 工具中更易于阅读。
页脚应包含对 问题的结尾引用 (如果有)。
样本(示例)
docs(changelog): 将变更日志更新为beta.5
fix(release): 需要依赖最新的 rxjs 和 zone.js
package.json 中的版本将复制到我们发布的版本中，并且用户需要其中的最新版本
还原
如果该提交恢复了先前的提交，则应以 revert: ，然后是还原提交的标题。在正文中应该说：This reverts commit <hash>., 其中哈希值是要还原的提交的 SHA 。
类型
必须为以下之一：
- build: 影响构建系统或外部依赖项的更改 (比如: gulp, broccoli, npm)
- ci: 对我们的 CI 配置文件和脚本的更改(比如: Circle, BrowserStack, SauceLabs)
- docs: 仅文档更改
- feat: 一个新功能
- fix: 一个 bug 的修复
- perf: 修改代码提高性能
- refactor: 既不修改 bug 也不新增功能的修改
- style: 不会影响代码含义的更改（空格，格式，缺少分号等）
- test: 添加缺失的测试或更正现有的测试
范围
作用域应该是受影响的npm软件包的名称（由读取从提交消息生成的变更日志的人所感知的）。
以下是受支持范围的列表：
- animations
- common
- compiler
- compiler-cli
- core
- elements
- forms
- http
- language-service
- platform-browser
- platform-browser-dynamic
- platform-server
- platform-webworker
- platform-webworker-dynamic
- router
- service-worker
- upgrade
当前，“use package name” (使用包名称)规则有一些例外：
- packaging: 用于更改所有软件包中的 npm 软件包布局的更改，例如公共路径更改，对所有软件包进行的 package.json 更改，d.ts 文件/格式更改，对包的更改等。
- changelog: 用于更新发行说明 CHANGELOG.md
- aio: 用于仓库的 /aio 目录中与 docs-app（angular.io）相关的更改
- none/empty string: 对
style有用，test和refactor
在所有软件包中进行的更改 (e.g.style: add missing semicolons)
标题（Subject）
该主题包含对变更的简洁描述：
- 使用
imperative/present tense: "change" not "changed" nor "changes" - 不要大写第一个字母
- 不要以 "." 结尾
正文（body）
与标题一样使用 imperative/present tense: "change" not "changed" nor "changes",z正文应包括改变的动机，并将其与以前的特性进行对比。
页脚（Footer）
页脚应包含有关 Breaking Changes (重大变化) 的所有信息，也是引用此提交关闭(commit Closes) 的GitHub问题的地方。
Breaking Changes 应以单词 BREAKING CHANGE: 用一个空格或两个换行符。然后，将其余的提交消息使用在这。
可以在 本文档 中找到详细说明。
规范信息填写，应该基于 push 原子性操作，即一次只解决一类问题
参考：https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines
