在参与开发的过程，得益与平台提供便捷的开发流程，简化很多开发过程操作分支的步骤；也就很好奇，为什么研发平台怎么设计，考虑的点是为什么，便有了这次对主干研发的学习与记录。
当我们是构建软件项目的唯一开发人员时，可以根据个人喜好创建和修改代码。当我们为团队运行的项目贡献代码时，我们需要遵循一套标准化的指导方针并与其他团队成员精确协调。标准指南和协调的工作努力对于每个基于团队的软件开发项目的成功至关重要。
为了满足这一需求，世界各地的工程团队设计了许多开发工作流程。大多数团队使用 Git 进行版本控制和管理他们的软件代码。基于 Git 的两种最流行的开发工作流是基于主干的开发和基于特性的开发。Facebook、谷歌、Netflix 和许多其他科技企业的团队使用这些工作流程。
▐ Git Flow
release分支：发布分支，从develop切出分支测试或发布，发布完成后，把release合并到master和develop分支
hotfixex分支：从master切出，修复线上问题，修复后分支合并到master和develop分支
▐ GitHub Flow
相对Git Flow而言，GitHub Flow只有特性（feature）和主分支（master），当featrue合并到master之后，即部署生产。
优点：分支类型简单，能够频繁部署生产
缺点：没有release分支，没有很好回滚机制保障线上问题快速恢复；对于主干的可发布性保障极高
可能对于一些开源项目/个人项目，不要求过高的稳定性，也不需要预发/生产环境的场景，这种极致的简单，可能开发人员效率会更高一点。
▐ GitLab Flow
一般情况下，发布也是在主干分支进行，当需要隔离不兼容代码的时候，会从主干拉取固定的发布分支。图中红色圆点表示一次坏提交，在构建被破坏后立即被后面的提交修复了。
降低解决冲突的成本：开发人员在自己的分支上独自工作的时间越长，越难将变更并入主干。另外，当分支个数和每个分支上变更数同时增加时，合并难度会很大。 高质量的代码：日常工作中，不知道大家是否有一个习惯，合并代码通常会在项目的提测或上线前一段时间，日常的合并次数减少，转化到发布前处理大量的合并，以及大量的CR，该流程下，高频次的代码提交合并，将大块的代码切分到日常小块代码和CR，且合并需要通过相关卡口（构建、包依赖等），避免发布前才关注到CR和测试的问题 高效的持续交付：对于大规模的项目，主干分支保持鲜活（其他人的变动能够被及时感知），团队开发效率更好；不用等即可上线，基于特性分支迭代开发的模式，当多个变更集成到迭代时，一个变更完成，另外一个变更没有完成需要退出迭代；测试环境更加稳定，主干研发发布分支在固定分支上，当特性分支迭代有多变更情况，此时，创建的是一个临时发布分支，当有变更加入或退出时，会导致发布的环境不稳定。
对团队的基础架构和协作能力的要求很高，要求每次commit的代码能够独立运行，如果合入主干的commit出现问题，会阻塞团队的进度。 对团队代码质量要求高，评审机制要求完善。需要有完善的 CR 机制，将问题代码尽可能在发布的前置环节发现并解决。
工具函数的开发：
开发阶段：工具函数的需求功能点容易切分，比如 env、cookie 这些工具类函数，可以作为切分为小的代码块，在上线之前通过自动化测试/自测，保证ci通过后，即可快速上线，新增功能；其他人提交功能后，能够及时感知到master的改动点。
发布阶段：主干开发天然基于版本发布，可以支持不同功能的版本
bugfix：基于工具函数的bug，需要快速修复，通过CI后，合并到主干，发布修复的版本，不再拉取新的bugfix分支，解决可能存在的冲突问题。
基于特性开发流程：
基于主干开发流程：
总结
基于主干开发相对于分支开发的各种利弊，根据自己所在团队的实际场景来看待，选择用主干开发还是分支开发。如果主干开发的优势对自身产品可有可无，那么没有这种必要来切换。但是如果有必要，但是团队的成熟度和技能达不到，也不适合切换到主干开发。当选择要切换到主干开发，一定要有心里准备来应对变革过程中遇到的各种问题。当然当你的团队经历了这些阵痛并真正适应了主干开发，那么团队就的成长也是巨大的。
我们是大淘宝技术行业与商家技术团队，是消费电子线下业务，主要面向线下门店的分销、经营、零售相关的产品。技术侧属于大淘宝技术前端团队，技术产品服务阿里巴巴整个集团亿万级别的业务。