提交日志规范

提交信息一定要认真填写！

建议参考规范：(scope)：

比如：fix(首页模块)：修复弹窗 JS Bug。

type 表示 动作类型，可分为：

fix：修复 xxx Bug

feat：新增 xxx 功能test：调试 xxx 功能

style：变更 xxx 代码格式或注释

docs：变更 xxx 文档

refactor：重构 xxx 功能或方法

scope 表示 影响范围，可分为：模块、类库、方法等。

subject 表示 简短描述，最好不要超过 60 个字，如果有相关 Bug 的 Jira 号，建议在描述中加上。

提交粒度规范：一次提交只对映一个相关的改动

当你想要进行提交时，非常重要的一点就是，它只能包含一个相关的改动。也就是说，不要在一次提交中包含一些和提交目的无关的改动，每一种不同的改动要打包在不同的提交中。比如，在一次提交中既添加了一个新的功能（例如：用户注册功能），又包括了对一些错误的修复（例如：修复了Bug#122）：

• 理解这些复杂的提交对于开发团队里的其他成员来说是非常困难的。可能过了一段时间连你自己也糊涂了。你的队友不得不先要搞明白这个错误，弄清楚你为什么要同时修复它，之后才能试图了解这个新添加的用户注册功能。
• 不可能复原或者撤销其中一个改动。试想一下，那个新添加的用户注册功能可能存在很严重的错误，你想撤销它但是你又不想撤销那个修复错误的改动。你该怎么办呢？

也就是说，一次提交一定要包括一个且仅仅只能包括一个和提交目的相对映的改动：修复两个错误（最起码的）你要进行两次不同的提交。或者当开发一个新的非常庞大的功能时，你必须要把它分成几个小的并且在逻辑上有意义的提交，这样做可以有效地减少产生错误的可能性。

这种小的提交可以让开发团队的其他成员更好地理解这个改动。一旦发现这个改动有问题，就可以非常简单地撤销，而不会影响到其它的功能。

不要提交一个还未完成的工作

不要提交一个还未完成的工作，但这也并不意味着在提交前你必须要完成这个功能定义的所有需求。恰恰相反，对于一个很大的功能模块来说，要把它正确分割成小的完整的逻辑块，用来进行频繁的提交。但是，千万不要为了得到一个干净的工作副本（working copy）而提交一些不完整的改动。在这种情况下，你可以考虑使用 Git 提供的 “Stash” 功能。