Git工作流

一.分支管理

开发过程中主要存在以下分支：

- master
- dev
- hotfix-[问题名称][bug编号]
- feature-[功能名称]
- bugfix-[bug编号]
- refactor-[重构名称]

1. master分支

• 稳定的可发布版本
• 由发布人负责管理(合并操作)
• 不允许提交代码、不允许开发

2. dev分支

• 不稳定分支，功能完整，允许bug
• 原则上不允许直接在dev分支上进行功能开发，必须新建feature分支进行开发

3. hotfix-[问题名称][bug编号]分支

• 从master分支创建，横线后面跟上问题名称或者对应的bug编号，仅仅适用于生产线问题紧急修复！！！
• 修复完成，测试通过，合并到master和dev分支上，然后将此分支删除

4. feature-[功能名称]分支

• 从dev分支创建，横线后跟功能名称，用于新功能开发，每天下班前push提交到远程
• 开发完成以后，在远程发起向dev分支的合并请求，由指定的CodeReview人员审查通过以后进行合并，并删除该分支

5. bugfix-[bug编号]分支

• 从dev分支创建，用于修改测试提出的bug，横线后跟bug编号
• 修复以后，在远程发起向dev分支的合并请求，并指定提交者自身（或其他人）作为CodeReview，合并以后删除该分支

6. refactor-[重构名称]分支

• 从dev分支创建，用于代码的重大规模重构（小规模重构创建feature分支即可）
• 重构以后，必须经过严格测试通过，才能向dev分支合并

二. Commit提交规范

1. 备注格式

[类型描述]，类型如下图所示

类型	描述
feat	feature,即新开发的功能
fix	问题修复
refactor	重构代码
doc	增加文档(如ReadMe)、注释

fix:修复身份证含字母X的用户无法注册问题 
fix: 紧急修复生产线用户积分不显示的问题 
feat:商品详情页功能 
doc:增加项目readme文档，修改结算条款结算逻辑的注释

2. 提交频率

1. 每天下班前必须提交feature分支，并push到远程
2. hotfix、feature、bugfix、refactor分支尽量按照功能点或修复重构的问题及时commit（不要求push）