一、分支开发模式
1.Git-Flow 模式
标准的 Git-Flow 模式一般会包含以下几种分支：
feature 分支：开发者进行对应功能开发的开发分支。
develop 分支：对开发者开发的功能进行集成的分支。
release 分支：负责版本发布的分支。
hotfix 分支：对线上 bug 进行热修复分支。
master 分支：最新线上代码的基准分支。
2.GitHub-Flow 模式
GitHub-Flow 模式相较于 Git-Flow 模式更为简洁，没有了 Git-Flow 模式中 develop ， hoxfix 和 release 分支，对于 GitHub-Flow 模式来说，发布版本应该是持续的，快速的。feature 分支即 develop 分支，master 分支即 release 分支，对于 hotfix 的处理，GitHub-Flow 模式认为本质上也是特性修改，处理方式和 feature 分支理念是一致的。总的来说，所有特性修改都能快速集成到 master 上发布，小步快走，快速迭代。
3.GitLab-Flow 模式
GitLab-Flow 模式相较于上两种模式，提供了一种比较中和的选择，既不像 GitHub-Flow 模式简单，也不像 Git-Flow 模式臃肿。最大区别是体现发布侧，引入了 Pre-production 和 Production 两种发布分支，分别对应预发布和发布环境，master 则对应的是集成环境。
优势：
分工协作规则明确。整个开发周期中的各个步骤基本都有对应的分支，对于开发人员只需要遵循规则，在对应分支上进行对应的开发工作即可。
特性开发周期相对宽松。因为特性分支是有对应的开发者负责，所以对于一些较大较复杂的特性可以在特性分支上开发完成后再合入主干。
特性测试相对友好。特性功能的测试在特性开发分支关闭前都可以进行，这给测试预留了较多时间，对测试的能力要求也相对宽松，很多时候都可以进行手工测试。
劣势：
分支管理复杂。因为特性分支开发的基础就是多个分支协作，所以必然会创建很多不同的特性开发分支和特性基线分支，如果有些分支在生命周期结束后开发人员没有及时进行销毁，时间一长，必然会造成无效分支冗余，管理成本将会越来越高。
学习成本高。因为特性分支开发模式中不同的分支有不同的功能，代码在分支上的流转也需要遵循一定的规则，且不同的团队的规则也会不同，这样对于开发人员的学习成本很高，且因为分支较多，在代码的流转过程中也会增加出错的几率。
合并冲突多，迭代速度慢。因为特性的开发都是要在整个特性开发完成结束后才合并到主干分支上，这就意味着特性分支与主干分支一定会存在较多差异，并且特性分支的生命周期越长，与主干的代码差异越大，合并冲突也越多，解决冲突相应的时间和人力成本也会越高。同理迭代速度也会越慢。
需要较多的测试环境。每个特性分支的测试都至少需要准备一个测试环境，且在该特性通过测试前会一直占用，所以并行的特性开发数量会受到限制。
适用范围：
特性功能开发/测试周期比较长，测试主要依靠人工测试的产品。
版本迭代速度不需要太快的产品。
二、主干开发模式
主干开发模式是指所有的开发人员仅在一个主干分支（master）上进行协作开发，一般不允许新建其他长期存在的开发分支，所有的代码提交均需要在主干分支上完成。
通常这种开发模式下，开发者需要有较高频率的代码推送行为，一般一天至少提交一次，当主干分支达到发布条件后，就从主干分支上拉出发布分支（release）进行版本发布。
开发或测试过程中发现的代码缺陷也会直接在主干上进行修复，再根据实际需求 cherry pick 到特定的发布分支或是进行新版本发布。
优势：
分支简洁，实践简单，分支管理成本低。
开发人员易上手，过程出错率低。
合并冲突少，解决冲突成本低。
版本迭代速度快，更符合持续集成和持续交付的理念。
劣势：
对团队的基础架构和协作能力的要求很高。若合入主干的代码质量出现问题将会阻塞整个团队的进度，所以一方面需要团队成员的个人能力和协作能力比较强；另一方面需要完善的持续集成能力的基础平台，提供回滚等快速解决问题的能力。
对团队代码质量要求高，评审机制要求完善。需要有完善的 CR 机制，将问题代码尽可能在发布的前置环节发现并解决。
自动化测试能力要求非常高。需要完善的冒烟和单元测试，确保每次合入主干的代码的正确性。因为主干模式合入代码的频率很高，所以人工测试肯定是无法保证及时响应测试需求，一定需要自动化测试。
需要有特性隔离方案。主干开发模式中因为特性功能需要拆分成很小的粒度，有时候特性功能需要相互依赖，但相互依赖的特性又无法保证同一时间上线，就十分有可能出现半成品特性功能，这时候就需要采用特性隔离方案将这些半成品特性进行隔离。
适用范围：
团队代码风格成熟，基础架构和配套工具完善的团队。
版本迭代速度要求快速的产品。
团队成员习惯 TDD（测试驱动开发），自动化测试能力强，覆盖率高的团队。
现状
JD内部技术研发部门采用的为分支开发模式（Git-Flow 模式），为避免分支过多造成管理困难，拟管理规范如下：
分支管理
单分支：合master时间点：release验证完冲突解决完，上线前一天合并到master,多版本的打tag
保护分支，即需要专人负责合并的分支。 条线负责人负责合并
上线后验证监控无问题，删除相关分支，时效性最多保留2周
只能release分支做预发UAT验证，只能release分支能合并到master
特殊情况：多个版本的用release版本来控制
分批提测内容指导原则
每次提测的内容必须是独立的，有价值的，可讨论以及可测试验证的；
内容平均，确保每次提测的内容在迭代的测试预估时间内；
高风险优先，尽早发现风险和问题是质量保障策略中重要目标；
分批提测拆分方法有以下几种：
从上往下： 按照数据链路， 先完成上游逻辑提测 功能优先： 先保障功能链路的走查， 再验证性能， 安全， 兼容等指标
从后往前：项目如果涉及前后端开发， 后端稳定接口可先提测 二八分发， 研发工作量投入80%的模块最好拆分到前批提测，这样可以预估项目质量，测试内容，尽早调整项目进度
先中间后两边： 先保障核心功能和主场景提测， 异常流场景可以稍后
少走回头路： 逻辑确定的模块优先提测，这样可以减少因不断修改带来的重复回归
价值至上：要优先满足版本或迭代中对业务价值最大的部分