ps：专业名词在尾部有注释
精简版（小团队开发）（1-3人开发）（1-10台服务器）
分支：master/develop
开发：
develop分支上解析本地分支，开发功能完毕后，提交到develop分支，通知测试测
测试：
看的是develop分支上的代码打包的程序，如果有问题，开发修复问题 git push develop develop to master : 一个周期内，大功能完成后，由开发手动同步至master分支
优点：
分支简单，搭建容易，解释容易，测试需要服务器较少（1台）
缺点：
1：develop to master 时，开发需要分批次同步太多的代码，即一次次的在master分支 cherry pick develop代码，容易出错；
2：如果开发在之前的git commit阶段，混合提交，会遇到一部分代码需要提交，一部分一部分不需要提交的场景；
3：如果git commit阶段的注释没打清楚，develop to master时，只能凭感觉提交
总结：对开发git操作要求比较高，需要会比较分支代码，需要git注释规范，需要解决冲突的能力，易错敏感点较多
标准版（中型团队开发）（3-10人开发）（1-10台服务器）
分支：master/develop/feature/fix/hotfix
开发：
从develop解析出自己的feature/fix分支，feature分支命名feature-xxx具体功能名字）/fix-xxx（具体功能名字），开发至feature/fix分支完成
测试：
开发打包自己的feature/fix分支至服务器，测试至服务器查看，如果有问题 git push feature-xxx（具体功能名字）/ git push fix-xxx（具体功能名字）
feature/fix to develop：
测试验证ok的情况下，feature/fix to master , 并可在此阶段，增加review操作，保证代码质量
develop to master：
大功能发布的情况下同步，master建立里程碑
优点：
1：feature/fix to develop ， develop to master 时，是整体提交，提交速度快
2：开发任务细化成了feature/fix/hotfix溯源更方便，合并的时候，有理有序，不会产生瓶颈
缺点：
1：feature/fix 在 测试阶段，如果还是一台服务器，容易引起冲突，即多个开发同时都有属于自己的feature/fix需要合并develop，但是此时的feature/fix尚未测试，不确定是否达到要求，只能依次部署，排队合并；如果每个开发都单独部署一个测试环境，部署自己的feature/fix，需要的服务器大，部署前端环境需要额外的时间，和测试沟通需要时间。
2：遇到需要配合的功能，例如feature-a+feature-b=feature-c，feature-c才是需要的功能，则需要开发合并至feature-c才能提测，职责划分粒度较大，如果团队气氛不好，容易扯皮。
总结：对开发的git能力要求较低，对于服务器资源需求较高，但在1台测试服务器的情况下，部署效果要优于精简版，主要体现在有理有序、合并简单、开新分支容易几个方面，但分支模型向成员解释比较麻烦。
3：验收的压力集中在feature/fix to develop阶段，如果该步骤有没有review到的错误，则有可能将错误发布至master（生产环境），造成hotfix的来源。
总结：非常适合小团队、中型团队的开发模式
扩展版（大型团队开发）（10-100人开发）（k8s\docker\jenkens）
分支：master/uart/test/develop/release/feature/fix/hotfix
开发：
从develop解析出自己的feature/fix分支，feature分支命名feature-xxx具体功能名字）/fix-xxx（具体功能名字），开发至feature/fix分支完成
测试：
开发提交代码，由devopts平台（jenkens流水线\docker\k8s）自动拉取release-xxx分支创建出release-xxx分支（可以在jenkens流水线时引入自动化测试，如果测试失败不创建分支，直接给开发发通知失败），由devopts平台创建出部署release-xxx分支代码的容器并启动，测试登录该容器验证功能是否完成，如果没有完成，测试通知开发有问题，让开发反工，开发反工，提交再次提交feature分支，由devopts平台（jenkens流水线\docker\k8s）重新拉取拉取feature-xxx分支 提交 release-xxx分支并部署容器，如果测试至develop平台点击确认该功能完成，则由develop清除release环境，并将feature分支to develop分支
组合测试：
例如feature-a+feature-b=feature-c，feature-c才是需要的功能，feature-a、feature-b先提交，在devopts上手动的选择分支，点击创建环境按钮，生成含有feature-c功能的test-c的测试分支以及容器，供测试使用，有问题，由开发创建fix to develop ，再自动的创建test-xxx的测试环境（test-xxx+test-xxx的容器）
版本测试：
以 打tag的方式 给 develop 分支建立一个里程碑，有devopts平台自动创建test-xxx版本的测试环境（test-xxx版本+test-xxx版本的容器），有问题，由开发创建fix to develop ，再自动的创建test-xxx版本的测试环境（test-xxx版本+test-xxx版本的容器）
uart测试：
devopts平台上点击按钮手动的创建环境，拉取develop分支的代码，搭建uart测试环境，让测试使用，如果有问题，由开发创建fix to develop ，再自动的创建uart-xxx版本的测试环境（uart-xxx版本+uart-xxx版本的容器），如果ok，uart to master，再由devopts 发布部署 master分支代码至生产环境代表该功能结束
优点：
1：分任务的粒度可以更细，减少扯皮，进度跟踪可以更加的精准明了
2：测试场景划分更加细，各种不同的场景，都可以让开发快速的修复
3：因为经历几轮情况，漏测的情况大大减小
4：测试灵活，可以应对组合测试的情况
5：有uart测试，可以拟真服务器环境，发现线上才能出现的问题
6：devopts承担了大部分的自动化部署操作、一部分的常规测试，开发、测试可以减少更多的杂活，把精神聚焦于任务的开发
7：开发需要的git操作要求更低
缺点：
1：devopts部署需要时间，也需要资源，对于服务器的要求高。
2：需要有很多的人力，单人单岗位，1个开发配2个测试，确保功能没有问题，并且uart环境测试、版本测试都需要n个人力的测试投入，开发的调度问题是1个挑战，需要合理的调度，不然会造成一大堆开发等着测试测出问题，人力闲置的情况（如果项目代码质量把控到位的话，所有人些的代码都是一种风格，可以安排较少的开发承担修复错误）。
总结：优点很多，不过只适合大型团队玩，因为需要的资源、人力多，如果小团队上这种分支模型，反倒是优点高射炮打蚊子的形式
主要分支：
master【主分支】：为稳定的版本分支，每一个节点的代码均为可发布的。
release【预发布分支】：develop开发一个功能版本的时候，分析出Release分支，Release用于修复开发功能版本中的bug，Release完成后，同时分发到develop、master分支
develop【开发分支】：主要用于开发，其包含多名工程师提交的代码。
features【功能分支】：每一个工程师在开发新功能时以dev分支为基础创建的分支。
release【预发布分支】：一般用于功能开发完毕，所有工程师的代码进行最后的测试与bug修复的分支。
hotfix【热修复分支】：一般用于紧急修复现网运行程序的bug。
fix【日常维护分支】：修补bug
test【日常测试分支】：测试主要功能
uart【预生产分支】：专门测本地没问题，线上有问题的分支，uart环境需要和master（生产环境）保持一致
其他分支：
docs【文档分支】：补充一些文档
tyle【格式分支】：格式(不影响代码运行的变动)
refactor【重构支】：重构(即不是新增功能，也不是修改bug的代码变动)
chore【工具分支】： 构建过程或辅助工具的变动
