最热的瓜，居然让我吃懂了git 工作流？这份大厂分支管理的武林秘籍请速速收下！

本文链接：https://blog.csdn.net/qq_29966203/article/details/105740624

文章目录

写在前面

从昨天开始天降猛料，罗志祥的瓜猝不及防，让我整整两天疯狂吃瓜，无心工作，不幸拥有了闻者色变的黑眼圈。
可能很多人都对其高效时间管理叹为观止，我也对此颇为震惊，对此做了一番思考并延伸到自身热爱的工作——coding中！

结果惊讶地发现"小猪"同学与git对团队项目的管理模式居然有着异曲同工之处！

（莫非猪同学在凌晨4点给女朋友温馨电话煲之后还会偷偷学一波编程？）

下面，我将结合实战案例，来教教大家git是如何高效地对一次多人项目进行管理。

如何用git高效多人开发？

先简单介绍一下分支模型

什么是分支呢？可以理解成在一次产品迭代的过程中，不同时间段应该做的事情：

master ：【发版分支】在应用商店正式发布的版本就是基于发版分支打出来的包
alpha：【灰度分支】只合入影响不大的bugFix
release ：【集成/回归分支】合入bugFix
develop ：【开发分支】是一条不稳定的分支，开发期间所有feature都可以在任意时候合入
feature ：【需求分支】每一个新的需求会从dev分支拉取一个feature分支进行开发

看到这里，你是否有点惊讶。一次简单的迭代，居然有那么多分支？我都乱了。
莫慌，下面带你走进实战 ——

用一次项目实战来说清分支管理

场景一：需求评审阶段
一次版本迭代应该有明确的需求，就如同一次yp需要确定好对象。
在需求评审结束后，小组组长会为组员分配新需求，身负重任的我们兴冲冲地从devlop主分支上拉出一条属于自己的feature分支（注意起名要规范，一般是feature/[版本号]/[需求简写]），开始研发的不归路……

	// 从develop拉取一条新的分支
	git checkout -b feature/v1090/my_first_feature origin/develop/v1090

为什么每一个feature都需要单独去拉一个feature分支进行开发呢？我想这里的道理大家都明白吧。设想一下，你在开发需求A时开发到一半，这时候有个妹子突然约你吃饭。你二话不说，先把代码push上去，等到吃完饭再回来继续。如果你的这份"不稳定"的提交导致某个功能崩溃，整个团队的工作被你block住。等你吃饱喝足回来后，等待的就是一场腥风血雨……

场景二：开发阶段
当拥有了属于我们自己的一条feature分支后，就可以开始在我的主战场大干特干了！调研，开发，自测，熬夜，掉头发……辛辛苦苦忙完那么久后，我的feature分支终于能够按照产品需求文档的描述跑起来了！

但仍然漏洞百出。家丑不得外扬，在正式交付之前需要保证它的稳定。

接下来便在自己的feature分支上打包并上交提测。在一阵相爱相杀，硬磕死磨后，终于换来测试小姐姐微微颔首：“准”。我的feature分支也从一条不稳定的分支成为了一条稳定的分支。

已经拥有了合入develop分支的资格了！
在这里插入图片描述

场景三：集成阶段
不知不觉到了集成的阶段。各路大佬将他们完成的feature分支逐渐合入了dev分支。此时版本的build master开始在群里大声嚷嚷：

“ 8点发车啦，要上车的抓紧了！ ”

在这里插入图片描述

自称准时小公主如我怎么可能会落下每一班车呢？最后review了一遍代码，保证正常运行并且码如其人，规范性优雅性完全没有问题后。合入develop～

	// 将本地代码推入develop分支
	git push origin develop/v1090

此时feature分支已经寿终正寝，为了防止远程/本地堆积过多不必要的分支。此时可以使用

	// 删除本地分支
	git branch -d feature/v1090/my_first_feature
	// 删除远程分支
	git push origin -d feature/v1090/my_first_feature

进行删除～

场景四：回归阶段
此时这个版本所有的需求都已经合入dev分支。BM从dev分支拉出了一条release回归分支，交给团队进行回归测试。
什么是回归测试呢？就是对所有功能（尤其关注此版本feature相关联的功能）进行大杂烩的测试。
如果说feature分支上的测试可以说是针对某功能的测试，那么回归测试可看作整个App功能与质量稳定性的整体测试。
回归阶段不合入任何新的需求，解决的bugFix集中提交到release分支上，回归结束后会再合入develop分支。
在这里插入图片描述
此阶段是RD与QA之间一次博弈，一次战争！过来人衷心奉劝，一定一定要与QA搞好关系！

场景五：灰度阶段
灰度阶段是将app新版本发放给一定量级的线上用户进行体验。此时的app已经是通过层层考验，保证稳定运行的。

但是世事难料，你永远想象不出来中国网民各路神操作。
因此在线上仍可能会出现一些异常的case导致的bug。BM会从develop分支上再拉出一条alpha分支用来灰度。
灰度阶段一般不合变化较大的bugFix，只对明显的崩溃bug与细微的改动进行修复。

在这里插入图片描述

场景六：发版
终于到了发版的阶段！🎉🎉🎉
灰度结束后BM会将代码提交到master分支并打正式包交给应用商店，稍等一会会，我们就能在各大手机应用市场看到我们新鲜出炉的app啦！

在这里插入图片描述

激动的心，颤动的手。赶紧下载，点开app，体验一下自己写出的功能。完美酷炫，爽到不行～

带你们画一画小猪的分支模型～

本人也抱着对学术（八卦）无比热爱与刨根问底的态度，画出了罗志祥是如何用git分支管理的理念来进行时间管理，下图全凭乱想，仅供娱乐～

在这里插入图片描述

各路大佬也可以试着画一画小猪的时间管理模型，如果抓住了诀窍。请不要保留地分享给大家。
毕竟人人都想掌握【 多人开发 】的诀窍。

写在最后

上周和同组RD一起开发时由于没有清晰的分支意识，写了一堆未开发完成的代码提交到公共分支上。导致项目连连编译错误、崩溃，整个小组为了解决由我导致的bug花了整整一天的时间。
事后被小组组长狠狠教训了一顿。痛定思过。保证每次合入前都仔细review自己分支情况和代码稳定性，不会因为自己的过失block别人进度。
在这里插入图片描述