GitCommitLog提交规范

　　commitlog规范的意义：便于程序员对提交历史进行追溯，了解发生了什么情况。一旦约束了commitmessage，意味着我们将慎重的进行每一次提交，不能再一股脑的把各种各样的改动都放在一个gitcommit里面，这样一来整个代码改动的历史也将更加清晰。格式化的commitmessage才可以用于自动化输出Changelog。commitmessage格式：
　　commitmessage最好是结构化表达，让每一位阅读者都能看明白是做什么事情。
　　精简版：ADD：添加某功能MODIFY：修改某功能FIX：修复某问题DELETE：删除某功能
　　专业版：type（scope）：subjectbodyfootertype（必须）
　　用于说明gitcommit的类别，只允许使用下面的标识。
　　feat：新功能（feature）。
　　fixto：修复bug，可以是QA发现的BUG，也可以是研发自己发现的BUG。fix：产生diff并自动修复此问题。适合于一次提交直接修复问题to：只产生diff不自动修复此问题。适合于多次提交。最终修复问题提交时使用fix
　　docs：文档（documentation）。
　　style：格式（不影响代码运行的变动）。
　　refactor：重构（即不是新增功能，也不是修改bug的代码变动）。
　　perf：优化相关，比如提升性能、体验。
　　test：增加测试。
　　chore：构建过程或辅助工具的变动。
　　revert：回滚到上一个版本。
　　merge：代码合并。
　　sync：同步主线或分支的Bug。scope（可选）
　　scope用于说明commit影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。
　　例如在Angular，可以是location，browser，compile，compile，rootScope，ngHref，ngClick，ngView等。如果你的修改影响了不止一个scope，你可以使用代替。subject（必须）
　　subject是commit目的的简短描述，不超过50个字符。
　　建议使用中文（感觉中国人用中文描述问题能更清楚一些）。结尾不加句号或其他标点符号。根据以上规范gitcommitmessage将是如下的格式：fix（DAO）：用户查询缺少username属性feat（Controller）：用户查询接口开发body（可选）
　　改动内容多的话，可以换行继续描述详细改动footer（可选）
　　有不兼容场景用Breaks结尾。feat（browser）：onUrlChangeevent（popstatehashchangepolling）Addedneweventtobrowser：forwardpopstateeventifavailableforwardhashchangeeventifpopstatenotavailabledopollingwhenneitherpopstatenorhashchangeavailableBreaksbrowser。onHashChange，whichwasremoved（useonUrlChangeinstead）commitloghookshell
　　在本地。githooks文件夹，commitmsg。sample改名为commitmsg。
　　然后sudovim把以下shellcopy到commitmsg。！binshCOMMITMSGcat1egrep（featfixdocschore）（w）？：s（Sw）if〔COMMITMSG〕；thenechoCommitMessage不规范，请检查！exit1fiif〔｛COMMITMSG｝lt15〕；thenechoCommitMessage太短了，请再详细点！exit1ficommit
　　不规范提交：header填写xx（util）试试
　　image。pngmaven
　　也可以用mavenplugin动态生成shell，这样可以持久化check功能到git。