前言
之所以制定Git提交规范，是因为公司内有很多人对提交信息和提交内容都不重视，具体表现在2个方面：
- 提交信息随便写，例如 up、1。
- 提交内容很随意，什么时候想提交了就提交，经常一个提交会包含多个提交内容，例如新功能开发、BUG修复、文件夹结构调整等等经常包含在一个提交里。
这篇文章对提交信息和提交内容这2个方面都制定了相关规范，最终目的如下：
- 只需要浏览提交信息不用阅读提交内容即可知道此次提交做了什么。
- 每一个提交都是完整且独立的；
完整性体现在以后的任意时间回滚到此次提交都可以直接运行项目，
独立性体现在一个提交仅包含一个修改内容。
制定实施以后效果非常好，所以稍微总结了一下并发表出来，希望能帮到大家提高效率。
实施以后部分好处如下：
- 想对某1个版本进行整理，列出添加了哪些功能、修复了什么问题，之前需要手动查看每次提交的具体内容，然后记录下来，这个过程不仅耗时，而且极易出错；现在只需要将指定时间段内的提交信息打印出来，然后根据提交信息做一些简单的删除修改操作即可，不用去看具体的提交内容。
- 有时候某一个分支需要应用某一个功能，但是这个功能进行了多次提交，而且并不集中在一块；由于提交信息规范了，只需要利用
git log --grep命名即可找出所有关于这个功能的提交，然后使用git cherry-pick命令应用即可。 - 考虑到文章长度，还有很多好处并没有列出……
提交内容规范
[必须] 保证每次提交都是独立且完整的，鼓励多次数少内容提交。
独立：
通常情况下，一次提交只允许做一件事。
完整：
每次提交都必须保证它是完整的，具体表现为以后任意时间回滚到这个提交时都可以直接运行项目。
小而独立的提交有以下好处：
1. 审查比较快。
2. 审查更彻底。
3. 不太可能引入错误。
4. 更容易合并。
5. 如果它们被拒绝，可以减少浪费的工作。例如你写了一个巨大的CL，
然后你的审查人说总体方向是错误的，那么你就浪费了很多工作。
6. 回滚更简单。
7. ……[必须] 涉及文件夹结构、文件夹名称、基类代码或影响范围很大的修改尽量作为一次提交，不要分散提交，也不要和其他修改一起提交。
有时候经常会出现开发一个功能时，突然要紧急修改一个BUG；
这个时候你并不想提交当前的代码，因为这个功能还没有开发完；
此时你有3种方式可以保证提交的独立性：
1. 在当前分支上做一次临时提交，但是不要推送到远程，
切换到一个干净的新分支上修改BUG，待修改完成后再回到原先的分支，
使用 `git reset --mixed` 命令回到提交前的状态继续开发新功能。
2. 使用 `git stash -u` 命令将当前工作区和暂存区的内容贮藏起来，
然后在当前分支或者新分支上修改BUG(建议在新分支上)，
待BUG修改完成后再使用 `git stash pop --index` 命令回到之前的工作状态。
3. 直接在当前分支上修改BUG，
修改完成后使用 `git add -p` 命令精确的贮藏BUG修改的每条内容，然后提交；
除非你对 Git 十分了解，否则不建议你使用此方法，因为难度很大。
提交信息规范
[必须] 提交信息要达到即使是新人，在不看提交内容的情况下也能知道此次提交干了什么，关于提交信息的格式与规范请参考 Commitizen格式。
一个好例子：
其他规范
[必须] 项目中创建Tag时统一使用附注Tag，附注Tag可以包含更多信息，方便后来人明白当初创建Tag的含义和作用。
[建议] 不要养成提交就立即推送的习惯，有些工具会默认提交就推送，请关闭它；没有推送之前，提交只存在于你的本地Git库，你如果不满意之前的提交内容和提交信息，你可以修改它直到满意为止，但是如果你已经推送了就不能这么操作了。
我们不是完人，有时候经常会遇到对之前提交的内容或提交信息不满意的地方想要修改，例如：
1. 某次提交的提交信息这样写可能更好理解一些。
2. 某次提交不小心漏提交了一个文件或一行代码。
3. 某次提交不小心多添加了几个文件或几行代码，而这几行代码应该属于其他提交。
我们经常会使用 `git commit --amend` 来修改上次的提交内容或提交信息，
使用 `git rebase -i` 来修改历史提交内容或提交信息。
但是这2个命令都会修改提交哈希值，如果修改前的提交仅存在于你的本地Git仓库，那这么做没有任何问题，
如果你已经推送了这些提交，或者这些提交存在于其他地方，那么将会发生问题。
简单的来说不要对任何已经推送的提交进行修改。
如果你真的不小心这么做了，请告诉你的同事，在下次拉取代码的时候使用 `git pull --rebase` 代替 `git pull`，
虽然这么做可能不能完全解决问题，但是可能会减少伤痛。
结语
- 可以转载，但是请注明来源。