1. 开发环境简介
DEV:Development environment,开发人员本地使用
FAT:Feature Acceptance Test environment,功能验收测试环境，用于测试环境下的QA/PM测试使用。
UAT: User Acceptance Test environment,用户验收测试环境，用于生产环境下的QA/PM测试使用。
PRO:Production environment,生产环境/正式环境
2. 分支简介
master 主分支，用于部署到正式环境（PRO），一般由 release 或 hotfix 分支合并，任何情况下不允许直接在 master 分支上修改代码
release 预发布分支，用于部署到正式环境（UAT），始终保持与 master 分支一致，一般由 develop 或 hotfix 分支合并，不建议直接在 release 分支上直接修改代码。如果release 分支测试出问题，需要在develop分支上去做测试。
hotfix 紧急修复分支，命名规则为 hotfix- 开头
当线上出现紧急问题需要马上修复时，需要基于 release 或 master 分支创建 hotfix 分支，修复完成后，再合并到 release 或 develop 分支，一旦修复上线，该分支要删除。
develop 测试分支,于部署到测试环境（FAT），始终保持最新完成以及 bug 修复后的代码，可根据需求大小程度确定是由 feature 分支合并，还是直接在上面开发。 开发人员本地开发测试完成之后，再提交合并到该分支。
feature 功能开发分支，命名规则为 feature- 开头，一旦该功能上线，该分支要删除。
3. 开发场景
3.1 新功能开发
比如会员功能
从master创建一个分支 feature-user，研发本地开发测试ok（DEV），合并到develop(FAT)，测试ok，再合并到release(UAT),如果没问题，合并到master，发布上线之后，删除分支 feature-user
中间如果某个环节有问题，在feature-user 分支下修改，重新走合并流程。
3.2 bug修改
比如 会员bug
从master 创建 hotfix-user 分支，本地开发测试完成之后(dev)，直接合并到master，发布到线上，进行测试，测试没问题之后，合并到release,develop,然后分支删除。
__缺点：__这种方式存在一定到缺陷，比如我release有功能在测试，从master拉出分支之后，如果合并过去，可能会导致测试功能的时候，有外在因素引发的bug，增加测试的复杂度。
4. Commit 日志规范
日志格式： <type>(scope)：<subject>
type: 类型
fix：修复 xxx Bug
feat：新增 xxx 功能
test：调试 xxx 功能
style：变更 xxx 代码格式或注释
docs：变更 xxx 文档
refactor：重构 xxx 功能或方法
scope： 范围
可分为：模块、类库、方法等
subject：简要描述