干货 | 单周多发场景下，携程机票基于Light Merge的自动化分支管理策略

作者简介

 

新友，携程前端工程师，主要负责机票主流程和机酒预订流程相关开发工作，对安卓和React Native有浓厚兴趣。

Heter Li ，负责携程GitLab代码平台研发，致力于高效的持续集成事业。

一、前言

随着移动互联网时代的高歌猛进，产品的研发迭代速度变得愈来愈快，工程复杂度越来越高，这对产品研发过程提出了高质量、高效率、更灵活的要求。在研发团队的开发协作上，开发人员遵循一套可靠且灵活的代码和分支管理准则。在机票主流程前端一周多次发版的背景下，对工程高效率迭代和持续集成的需求尤为迫切。不同研发团队在分支管理上有很多优秀的实践，更多的时候会根据团队以及项目特点选择最合适的分支管理策略。

Git分支管理策略其实就是通常意义上的Workflow，目前使用度最高的Workflow前三分别是Git Flow、GitHub Flow、GitLab Flow。基于机票主流程前端团队组成和项目特点等因素上的考虑，我们选择了GitLab Flow，本文将介绍机票主流程前端在GitLab Flow分支管理策略上的实践及演进。

二、分支管理的必要性

随着承接产品线的增加，发布的生产安全问题无时不刻都会存在，对代码的集成便有了更加精益的管理方式，比如对集成分支的保护、借助Merge Request的方式集成代码、建立Code Review规范等。在研发过程中借助分支管理上的一些经验和实践，以尽量减少和避免生产问题。

先说明下机票前端采用Fork仓库的开发方式。Fork服务于一个项目，经常使用在开源场景，当发现原项目存在bug或者有优化空间，可以把原项目Fork下来，相当于拥有一份原项目的备份，可以帮助作继续完善项目或者自行维护一个属于我们自己的项目。当修改完善之后，可以尝试发起Merge Request到原项目，在作者同意本次提交内容后上传的修改则被共享。

正是基于此理念，原仓库及分支被共享，同时借助了Merge Request的代码提交方式，保证了对原仓库每次高质量的代码提交，针对每次提交严格执行Code Review，杜绝向原仓库直接Push代码，对原仓库分支做严格保护。

三、几种分支管理策略

因研发团队成长和项目自身的特点，机票前端经历三种分支管理策略的演变，这三种分支策略在下文分别称之为单分支策略、多分支策略、正在使用的Light Merge分支策略。

在项目起初时，项目主要由固定团队开发和维护，研发工作相对单一，采用单分支策略。

为更敏捷的响应业务的变化和需求侧的多样，项目不再是由固定团队维护，反之由多个小团队单元参与迭代，同一项目在多个小团队单元之间共享，发布周期也较之前大幅缩短。这对团队协作和研发质量有更高的要求，在平时开发工作中采用多分支策略以隔离测试环境和生产环境，同时为了满足多个需求的并行开发引入功能分支开发方式。

考虑到多分支策略中不能提前暴露集成错误、多分支在管理上的开销等问题，通过对过去研发活动中的经验总结和流程规范，逐步总结出一套可被遵循的研发方法，由于持续集成的问题亟需解决，基于Light Merge的更加灵活便捷，同时结合CI/CD，于是采用了Light Merge分支策略。

3.1 单分支策略

各产品线都有固定的发布周期，事先约定产品线发布日窗口，在早期根据产品线的迭代周期从主干分支拉出开发集成分支，同一个产品线的所有开发人员均共享同一个开发集成分支。在开发周期结束后，从开发集成分支发起到主干分支的Merge Request，将代码合并到主干分支上进行发布。

优点