说到Git分支管理，自然最先想到经典的Git Flow工作流，来，先放张熟悉的图~~

你看，多美好的东西啊，流程很清晰，但是，很悲伤的是，它并不符合我们业务场景。没办法，不得不想出一套适合我们业务的Git Flow实践。

“奇葩”业务形态

我隶属于对外合作业务部门，主要职责是给外部客户提供SDK解决方案。部门工作内容主要分为两部分：内部定期迭代主版本；外部应对不同客户定制需求，提供不同定制版本。

所以相比正常开发流程要求，有如下几个特点：

1）规模上：需要同时维护的版本数量繁多，各个客户有各自不同定制需求。

2）时间上：客户版本周期不一致，反馈问题需要及时响应解决，处于持续发布状态。

3）稳定性上：由于是对外客户项目，犯错成本高，稳定性第一，甚至高于功能本身。

这样的业务场景，需要面临有很多问题，比如：

1）每个客户独立分支？还是尽量用主分支？

2）如果独立分支，一个客户报的严重bug需不需要merge到其他分支？分支中业务内容过于老，维护成本高怎么办？

3）如果仅主分支，如何管理这么多客户版本？一个bug会不会影响所有分支？

曾经实践过的方案

1）主版本定期迭代，客户版本一律从上一个稳定tag分支出来，独立维护

业务背景：初打江山，客户来一个伺候一个，跟爷儿似的不敢得罪

优点：客户版本独立分支，质量稳定、可控

缺点：客户版本往往严重落后于主版本；各版本间通用bug的merge机制不完善

2）只维护一个主版本，用丰富灵活的配置项来满足客户定制。

业务背景：客户越来越多，分支维护越来越吃力，同时业务变化快，要求客户尽可能及时更新

优点：减少客户分支数量，而且代码尽可能的包含最新业务内容（事实上并没有减少很多分支数，部分配置项满足不了的定制版本，以及临近封板量产的版本，最终还是要拉分支）

缺点：存在严重质量风险！试想，对同一客户，两次更新版本时间越久，包含新业务内容就越多，远远超过他自己反馈的问题本身，关键他还被蒙在鼓里。虽然现在看来，的确想想就不靠谱，但就当时业务发展需要，这已是折中的实践方式。

唉，可见由于业务形态特别，分支管理上，大家感觉特别心累，很多时候还不得不case by case处理。正是在这样的背景下，经过探讨，一套相对规范且适合业务的Git实践方式应运而生。

那该怎么做？

既然我们的业务需求分别来自内部和外部，那咱们分开来说吧。

一、内部功能迭代

内部功能开发迭代，基本参照git flow，因为它本身就是适合feature开发。不过强调几点：

1）master、develop设为保护分支，仅Master有权限commit和merge

2）开发阶段，任意改动（不光是feature开发，包括修bug、改文档、重构优化等等）都需要从develop拉分支，测试完毕后提Merge-Request，被Master代码审核后，才能merge回develop。

3）以15天为迭代周期，拉出release分支。这样是为了保证主版本迭代及时性，让任意时刻新来的客户尽量包含新的内容。

4）release分支上的测试周期控制在2-3天左右，坚决不可过长。

二、外部需求定制

1）每个新客户版本，从master分支最后一个tag拉出新分支，在此独立分支上完成所有定制。

2）制定mergelist机制。每天立会快速Review待新增的merge项，原则上通用且严重的bug。每次出版本前，对应Dev对照最新mergelist，查看是否有需要merge的内容。

3）每次出完版本需要打tag，便于追溯，用release脚本实现即可。

三、持续集成

使用Jenkins，比较常规，主要完成几件事：

1）DailyBuild

除了正常编译版本，还包括静态指标统计报表，如包体积、方法数、Findbugs、Checkstyle、Lint等等，精细到每个模块。通过观察基础指标的变化，及早发现问题、解决问题。

2）Release

相应Dev登录平台，输入不同客户参数，便可编译输出对应客户版本。

综上所述，主版本沿用git flow，用小步快跑的迭代频率，保持内容及时性；客户版本用独立分支管理，用mergelist机制来同步分支间bug；用持续交付平台，提高出版本效率。

总结

唯一的不变就是变化本身。业务永远在变化，公司发展到不同阶段，业务侧重点自然不同。无论是流程也好，架构也好，都要时刻警惕，一旦闻到“臭味道”，那就得重新改造，根据自己目前的实践情况，找到适合自己的，才是王道~~