【干货分享】大话团队的GIT分支策略进化史

 

封面

做为一名85后的技术男，一转眼10年过去了（一不当心暴露了年龄，虽然我叫18岁fantasy），亲手写代码已是5年前了，目前主要负责公司的软件产品的规划和设计（因此最近写的东西也主要与设计和产品分析有关）并带着研发团队进行产品落地。偶尔手痒痒写点代码或者和团队讨论一下架构设计啥的，毕竟之前是那么的热爱！

这篇文章主要想写写我所在团队git的使用历程，有些算是回忆吧。~老司机共勉啊~

SVN时代

在刚进公司的时候，那会你们都还在使用svn。代码，原型设计和过程文档都在svn上。大概过了一年，整合svn大小40个G（大概两个千万级项目的代码和文档），每次更新要人命，也给实施团队和方案团队带来了不少困惑，后来就直接把研发从svn上分出来了，但仍是svn管理，svn只用来作内部文档管理。

那个时候主要面对项目开发，团队也比较集中，都在北京，项目的特征就是一次性交付，后面有部分变动开发和bug修改。因此从分支上来讲基本上就是这样的。

单项目svn

你们都在主分支上开发，而后定时提交，到了上线节点QA把代码checkout下来开始测试。测试完后把bug清单发给研发，研发一顿改，以后提交，QA再回归测试，基本上没问题而后就上线了。

暴露问题：

随着时间的发展，你们有很多时间花在解决冲突上，由于其余人提交了有bug的代码（团队有要求必须自测后提交但，可是自测能力良莠不齐），有时候量大了能折腾一上午，基本上最后提交以前都得先本地备份一下，生怕应为冲突而代码丢失了。

引入GIT

随着业务的扩展和团队的发展，北京，武汉，长春都有了研发基地，这种扯皮的事情更多了，而且因为网络的不稳定，不少时候代码提交都出现了问题，经过内部沟通研究，决定将代码管理从svn迁移到公网码云（gitee）上，当时也研究了github之类的。最好考虑仍是用了国内的，毕竟还有社区啥的，平时吐个槽看个科技前言新闻也方便。

上了git以后，一开始也只解决了地域问题，你们能够在各自的城市畅通无阻的提交代码了，同时团队也增强了代码审核和自测培训。可是基本上没有分支的概念，那个时候，GIT的使用是这样的。

gitc之初

此阶段解决的问题：

分布式团队，分布式提交。

产生的问题：因为团队要求天天代码必须提交到远程。可是自测结果任然具备不肯定，bug仍是满天飞，天天一来仍是要处理冲突。

引入分支

经过团队讨论，代码天天下班远程提交是必须的，为了防止影响别人，就引入我的分支（团队任务基本上按人按模块分工，先后端不分离），因而就给了每一个人或者开发同一个模块的几我的建一个分支（若是同一个分支几我的之间有小矛盾内部本身解决吧），那个时候起名通常按照“项目名_模块名”起名，好比：dxplat_logmgr（下文暂时用git的专用名称feature代替）。天天写完代码，若是还没完成就先提交，而后肯定测试完以后再合并到主分支。

引入分支

解决的问题：

可按地域分布式提交。

可远程提交到本身的分支，不影响主分支。

产生的问题：

项目上线后，一个项目实施（简称A）完以后，另一个相同业务的项目（B）也中标了，可是需求还不尽相同。而且A项目在质保期，还得修修改改，添添补补。怎么能同时知足这两个项目并发升级上线呢。若是按照之前的方法，就是管你A和B，我就是一个工程，而后最后都是打一个包给你（说到这不少人应该有同感），同时包含A+B。实施人员你去部署吧，上线配置当心点改，A项目改A的参数，B项目改B的参数。

随着时间的推移，同业务域定制的项目愈来愈多，这样下去不是办法，因为上线时间不一致，主分支都不敢随便提交了，QA正在测试A项目的时候B项目也催的着急，也得提交代码让另一个AQ测试啊。并且代码也慢慢失控了，改起来别提多费劲了，各类依赖包整的项目臃肿的不行不行的了。

引入release分支

团队讨论以后，决定引入release分支，一个项目上线后，经过master创建release分支用来支撑不一样需求的项目，定时选择性的将不一样项目里面的模块合并到master，开发人员都基于release作开发，而且这个release会一直保留，由于用户永远都有当心思。同时新的项目来了以后都从mater再建立release去应付新的定制需求。整个开发流程变成下面的状况：

release

至此这个策略用了至少2年，一直坚持在用。而且对待项目型的开发整体感受用着还行，网上有人说少了dev分支，团队内部讨论总体感受对项目型不必再搞个dev分支，由于项目基本上是瀑布式开发直到上线，中间迭代上先次数基本不多，要上线也是全部需求知足直接上先。可是最后仍是用上了。

接着往下发展~

终于公司部分业务产品化了，也面向公众和企业用户了。需求也多了，面对竞争对手也必须快准狠的面对市场了。

总结产品和项目不一样的特征以下：

一、项目具备固定周期，项目结项完毕，开发工做也基本结束了，后期修修补补。产品固然也有周期，可是不是客户定的周期，而是企业战略和市场决定。

二、项目基本瀑布式开发，而产品若是竞争激烈，那就必须敏捷迭代，对需求池进行排序，快速跟进。

三、产品和项目都具备可复制特性。可是项目的复制因为客户需求的不一样，需求范围有很大的不一样，也就是所说的定制化程度高，基本上是方案和设计思想的复制，其余都是大量定制开发。而产品一旦肯定用户群和需求痛点这些大方向，基本上是一个线性开发的过程。不断开发迎合市场和企业战略的新需求，废弃不必和过期的老需求。

云端产品和终端产品的区别：

若是云端产品，那个全部用户都会感知一个版本。而若是是终端产品的话，不一样的终端用户群会有不一样的产品版本，根据公司策略和客户要求去升级。

那么对于产品化的分支策略，开发需不停的在完成需求池中需求的开发。市场则需根据市场策略上线不一样的版本，好比有的功能是技术公关，做为公司与竞争对手的pk点，就不能过于超前上线，以便被抄袭。有的是用户最关心就必须在竞争对手以前上线。

这个时候之前的分支策略问题就来了。必须有一个分支是时刻能上线的代码，并且能记录不一样的版本（有的版本上线后有bug，须要修改，可是用户也不须要新功能）。

引入TAG

经过在mater上记录tag来记录每次上市的产品版本，若是这个版本有bug，可是用户当前不须要新的需求，就直接在这个tag上建立临时的分支给用户改bug，改完以后代码将代码合并到master。这个时候咱们通常不删除这个临时分支，由于鬼知道后面还有啥bug呢，有点相似于release分支，可是和release不一样的是，这个只用来改bug，新的功能开发都必须在mater上。开发流程就变成了这样：

产品化分支策略

这里面的问题就是QA测试的时候master不能合并新的代码只能改bug。一旦合并新的功能，上线范围就变了，就得从新测试。必须测试完打上tag以后才行。可是有时候公司内部须对全功能进行内部演示和访谈调研，就必须有一个全版本的分钟，而mater做为发布版本，又能随便合并。怎么办呢，就是引入dev分支。

引入DEV分支

具体作法就是建立dev分支，版本上线是，合并到mater，QA从mater上pull代码作测试用于测试上线，有bug建分支改，改完bug，master和dev上都合并。可是这个时候dev上开发的新模块不合并到mater，你们提交仍是往dev上提交，内部演示都从dev打包作演示。下次上线依然是提交到mater让QA测试（这一块和网上不少人说的不同，你们都是从dev上作测试，而后没问题合并到mater）。这样下来分支就变成这样：

dev分支

有些地方会和网上的会有差异，好比咱们是在最后才引入dev分支的。

总结

一、针对项目和产品咱们采用了两套策略，项目用release策略，产品用tag策略。

二、另外若是是集中式开发的小团队小项目，只基于mater开发也不是不可，也挺灵活，加上严格的代码审核和自检培训就好了。

三、这里面基本也用到GIT的三种工做流的思想（Git Flow，GitHub Flow，GitLab Flow），加入了本身的一些实践和定制。

关于pull request

对于git中的pull request协做机制，实际应用中也基本没用上，感受比较适合外包或者开源协做项目（多个不太熟悉的小团队合做开发一个项目）。若是是内部团队，毕竟这种协同机制内部定死也不必线上处理了。

咱们的代码审核时间有时候不在上线前，基本上会周五或者周一由专人进行（一方面审核代码及完善审核规则，一方面培训新人），而并非提交一个模块就让人审核，这样若是功能点太多，审核人的时间就很零碎。可是上线的功能确定是审核过了的，并且会有严格的代码测试。

---

零零碎碎也了不少，欢迎你们一块儿讨论吧，有问题也欢迎留言提出。

总之，适合本身团队和公司的就是最好的，用发展的眼光看待技术。