前言：在我们程序员做项目的时候，大多是多人完成一个项目,要处理好规范文档， 是很重要的，在我们规定git 提交规范的时候,各个团队和各人都有不同的准则或是考量，摸索出适合自己的一套很有必要，也许这个规范可能会伴你一生。就如我刚开始写代码的时候，我的师傅就对我的代码规范很严格，而我也一直遵循着他的规范,慢慢的就成了习惯，期间也有自己改过一些适合自己习惯的规范,但是默默的就形成了自己的一套习惯，那么git commit 的规范 对团队有多大益处呢？加入一个团队有6人，其中4各人都遵循一个相同的规范，而另两个人各有各的规范，不管他们代码有多好，看着commit 记录就会显得格格不入。
没有好的规范，只有适合自己，自己适合的规范。我们遵循一个规范，是为了适应团队，而不是给其他人找麻烦。
一般情况下，提交 GIT 时的注释可以分成几类，可以用几个动词过去式或者动名词开始：
Added ( 新加入的需求 ) Addition
Fixed ( 修复 bug ) fixing
Changed ( 完成的任务 ) change
Updated ( 完成的任务，或者由于第三方模块变化而做的变化 ) update
尽量将注释缩减为一句话，不要包含详细的内容。
或者这样的
feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
style： 格式（不影响代码运行的变动）
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
test：增加测试
chore：构建过程或辅助工具的变动
我们在 敏捷开发的时候也会用到redmine，bugzilla这样的bug追踪系统，我们可以在修复bug 的时候加上 对应的id比如
fix bug : #1000 修复数据排序问题
这样的提交信息
我自己的提交信息基本上分为几类
1 fix bug: #1001 修复分页问题
2 feature: 新功能
3 modify: 修改代码, 这步是本身代码没有bug,只是想到了优化代码，使程序更简洁更优雅
4 refactor: 重构
5 doc: 添加修改文档，比如readme.md
6 style: 代码缩进或是空行太多,显得比较乱,修改后可以用style做提交信息
7 test:添加测试用例
8 chore:构建过程或辅助工具的变动
综上，只有fix bug 的时候, 才会有 #1000 这样的表示，因为bug已经存在了，其他的都属于新增或者删除，不需要bug id
至于changelog, 我就没有考虑过了