Git提交规则
推荐的分支管理：
master分支为主分支（保护分支），禁止直接在master上进行修改代码和提交，此分支的代码可以随时被发布到线上；
develop分支为测试分支或者叫做合并分支，所有开发完成需要提交测试的功能合并到该分支，该分支包含最新的更改；
feature分支为开发分支，大家根据不同需求创建独立的功能分支，开发完成后合并到develop分支；
fix分支为bug修复分支，需要根据实际情况对已发布的版本进行漏洞修复。
标签Tag管理：
Tag采用三段式：v版本.里程碑.序号（v2.3.1）
架构升级或架构重大调整，修改第1位
新功能上线或者模块大的调整，修改第2位
bug修复上线，修改第3位
当然，可以根据实际情况来设计，比如项目特别大，可以使用四段表达Tag，项目比较小也可以使用二段式Tag，只要符合场景并有实际意义即可。
提交信息格式：
下面只是提供一种建议格式，大家可以根据自己的项目实际情况来定格式，只要能把当前提交表达清楚，格式统一，方便快速阅读和定位即可！
建议中文示例： <新功能>（urllAnalyz）添加解析url功能 <修改>（TestServiceImpl）修改某功能的某个实现为另一个实现 <Bug修复>（TestUnti）修复url特殊情况下解析失败问题（issue#12） <重构>（getData）重构获取数据的方法 <测试>（getDataTest）添加（修改、删除）获取数据的单元测试代码 <文档>（doc）修改（添加、删除）文档对应到英文：
feat：新功能（feature）
style：格式
fix：修补bug
refactor：重构
test：测试相关
docs：文档（documentation）
格式（type：scope：body：issue） <|新功能|修改|Bug修复|重构|测试>（影响模块）提交描述信息（#issue?）优点作用：
与github数据issue关联，便于通过issue获取更多信息
commit 提交时，格式统一，便于后续快速准确定位提交
可以更好的将此次提交表述清楚
