仓库结构
Git仓库中的分支：
-
master分支，是项目的发布分支，分支中的代码必须是最新版本的可运行版本的代码，提交测试的版本和最终对外发布的版本都从这个分支出 -
develop分支，项目的开发主分支，只有项目通用的功能代码的开发工作在这个分支做 -
feature/somefeature，特性开发分支，每一个独立的功能都在一个单独的特性开发分支上进行开发，开发完成后再将该分支合并到develop分支 -
release/somerelease，版本发布分支，版本的发布及测试提出BUG的修改都在这里进行 -
hotfix/somehotfix，BUG修复分支，所有由测试提的BUG都在这类分支上修复，可以是每一个BUG对应一个分支，也可以一系列BUG对应一个分支，根据实际情况调整
feature和hotfix分支都要在对应的开发完成后删除，如果不涉及到多人协作，禁止将这类分支push到远程仓库
功能开发(feature)
- 从
develop分支打出feature/功能名的分支 - 如果在开发过程中，如果
develop发生了影响到该功能的变化，允许从develop分支合并新的代码进来，关于合并方式，请参考文章最后“一个典型的开发人员提交流程” - 开发完成后，将功能分支合并到
develop分支，并提交********评审********请求 -
Review通过后，将develop分支push到远程仓库，并删除feature分支，开发过程完成
版本发布(release)
产品的某个版本开发基本结束，从提交测试直到该版本正式发布的过程中，对代码的所有变更都在Release分支进行。Release流程的操作步骤：
- 从
develop分支打出release/x.x.x(版本号)的分支 - 从该分支打出测试版本，提交测试(编译版本的版本号格式:x.x.x-编译日期-第几次编译)
- 在
release分支修复测试提出的BUG，push到远程仓库，直到测试全部通过 - 将
release分支合并到develop分支和master分支，并在master分支上打出x.x.x的tag
5.删除release分支
紧急修复(hotfix)
紧急修复是指已发布(生产环境)版本发生问题需要立即修复时的开发流程，一般是要针对master上的某个tag版本进行修复。步骤：
- 从
master分支的某个tag上打出hotfix/bug名称的分支 - 修复之，提交测试，同时提交********评审********，确保不会对生产环境产生不可预期的影响
- 测试和评审通过后，将
hotfix分支合并回develop和master分支，并在master分支打上新的tag，tag名称格式：x.x.x-hotfix-bug编号 - 删除
hotfix分支
