git规范

分支使用规范

代码库中分为master，develop这个是公共的团队分支；
feature分支用于功能开发，可以有多个，可以以feature-xxxx的方式进行命名,其中xxxx是功能或模块的名称；
fix分支用户修改bug，可以有多个，可以以fix-bugid的方式进行命名，其中bugid可以是bug号和bug名称；
开发时首先从develop中拉取分支，建立featrue-xxx或者fix-xxxx分支，以上的命名注意不要重复；

提交注释规范使用git template

完成代码开发或者临时提交时，可以进行提交，使用git template的工具进行编写提交说明；规范如下：

perf(装修首页): 使用传统方式进行接口调用

this is a long text description

commit模板具体说明如下：
fix(<模块>): <描述>
#<具体描述>
#<问题单号>
# type 字段包含:
# feat：新功能（feature）
# fix：修补bug
# docs：文档（documentation）
# style： 格式（不影响代码运行的变动）
# refactor：重构（即不是新增功能，也不是修改bug的代码变动）
# test：增加测试
# chore：构建过程或辅助工具的变动
# scope：用于说明 commit 影响的范围，比如数据层、控制层、视图层等等。
# subject：是 commit 目的的简短描述，不超过50个字符
# Body：部分是对本次 commit 的详细描述，可以分成多行
# Footer：用来关闭 Issue或以BREAKING CHANGE开头，后面是对变动的描述、以及变动理由和迁移方法

代码提交规范使用rebase

在没有开发完成的时候可以在完成某个小阶段之后可以进行commit，可以push也可以不push，在完成大版本的时候一定需要commit并进行说明；但是在合并到develop的时候一定要基于develop进行rebase；如果出现冲突可以进行冲突解决，或者新建分支并使用cherry pick把已经完成的工作cp到新的分支中重建分支；如果有必要的话可以使用force push进行强推一下；

PR规范

确保开发分支，和develop没有冲突，然后新建PR到develop中，并进行代码审查和比较的测试，如果没有问题使用扁平合并，这样子会让所有的commit合并成一个大的提交版本；

代码审查规范

代码审查流程和规范，请参照具体文章；
具体就是：功能背景介绍，功能设计和实现介绍，代码规范检查，功能实现检查，新设计和新技术的应用介绍等；