最热的瓜，居然让我吃懂了git 工作流？这份大厂分支管理的武林秘籍请速速收下！
文章目录
写在前面
从昨天开始天降猛料，罗志祥的瓜猝不及防，让我整整两天疯狂吃瓜，无心工作，不幸拥有了闻者色变的黑眼圈。 可能很多人都对其高效时间管理叹为观止，我也对此颇为震惊，对此做了一番思考并延伸到自身热爱的工作——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别人进度。
总而言之，git是用来对团队合作进行管理最好的方法之一，基本是互联网公司开发不可或缺的道具。用好git能给项目开发带来极大的便利。
一定要好好学习，好好应用呀～
最后说句题外话，罗志祥的事轰轰烈烈，再次刷新了我对渣男的认知。我想跟所有程序媛包括处于科技行业领域的女性说一句：
请自立自强，你的技术和能力决定你的高度；请不要为任何一个男人低头，因为你值得拥有你想要的一切。