场景
以后台开发为例，假设当前版本为a.b.c，一个项目的维护大概会发生三种情景，
1、产品提出一堆需求，考虑升级新版本，我们可以在原来的项目版本b+1，如果接口改动比较多，无法兼容client，可以clone新的版本a+1，此时接口可能由原来的http://api.demo.com/v1变为http://api.demo.com/v2，保证兼容老的client。
2、产品提出几个简单需求急需上线，可以在原来版本c+1。
3、线上环境出现一个bug，可以在原来的版本c+1。
流程
开发组
项目组
分支
develop
主线开发分支，场景所开发的所有新功能分支都是由此checkout。
feature
主线功能分支，由develop checkout，一般名称为feature_A，feature_B，该分支为临时分支，将来PR到develop。
hotfix
热更功能分支，由master checkout，一般名称为hotfix_A，hotfix_B，该分支为临时分支，将来同时PR到develop和master。
bug
bug功能分支，由master checkout，一般名称为bug_A，bug_B，当然也在hotfix上修改bug，也就不存在该bug分支了，该分支为临时分支，将来同时PR到develop和master。
master
线上环境分支，该分支更新方式为merge develop分支。
原则
- 任何没有通过PR的代码，都是垃圾代码，都尽量不被其他开发者引入到自己的远程分支中。
- 主线开发develop过程中，尽量将需求分解成多个模块，多个功能，模块多可以减少冲突，功能多缩短PR周期从而保证每个feature都可以短时间得到最新的develop代码，从而减少冲突。根据模块提issue，建分支fearture_index，根据个人喜好在该分支上开发若干功能，一旦功能开发完成，将WIP->revsole，代码审核人员通过，然后该issue再次新建分支fearture_index，并PR，每个人3天内至少PR一次（就是觉得完美了）。
- 某个featrue PR通过后，就可以删掉对应的远程了。本地根据自己需要是否保留。
- 开发过程中，尽量保证只有一个bug分支，即尽量保证bug_A，bug_B不会同时出现，bug_A中一般包含若干bug，也就是说bug_A是一次性发现和解决若干bug的集合，当然可以多人同时开发bug_A。hotfix同理。
- PR如果产生冲突，一定必须让提交者自己解决冲突。
- 每个PR都是由issue产生，并且，在分支被checkout时候就开始PR了，你会了吗？
部署
部署分很多方式，这里简单介绍三种：
1、git部署，即线上环境git pull方式。
2、release包部署，即线上环境解压包方式。
3、容器镜像部署，即docker pull、docker run，该部署方式尽量要有和线上环境内网容器镜像仓库，保证pull质量。
