android git提交整个项目_成功入职字节的小姐姐：吃最热的瓜，分享最有效的大厂分支管理，git 工作流...

最新推荐文章于 2023-12-06 11:42:04 发布

weixin_39583623

最新推荐文章于 2023-12-06 11:42:04 发布

阅读量96

点赞数

本文链接：https://blog.csdn.net/weixin_39583623/article/details/112138252

版权

android git提交整个项目

大家还记得罗志祥的多人运动吗？我没想到我挺喜欢的这个字节的小姐姐居然也关注了，哈哈哈，我一定要和大家分享一下这个文，大家可以 提前感受一下大厂的运作魅力。PS：小姐姐豪爽！爱了！

关注我的专栏，里面会定期分享相关学习经验和知识点，大家一起学习，共同成长，也欢迎投稿，分享自己的故事和学习经验~

Android进阶技术zhuanlan.zhihu.com

一、写在前面

从昨天开始天降猛料，罗志祥的瓜猝不及防，让我整整两天疯狂吃瓜，无心工作，不幸拥有了闻者色变的黑眼圈。

可能很多人都对其高效时间管理叹为观止，我也对此颇为震惊，对此做了一番思考并延伸到自身热爱的工作——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能给项目开发带来极大的便利。

一定要好好学习，好好应用呀～

最后说句题外话，罗志祥的事轰轰烈烈，再次刷新了我对渣男的认知。我想跟所有程序媛包括处于科技行业领域的女性说一句：

请自立自强，你的技术和能力决定你的高度；请不要为任何一个男人低头，因为你值得拥有你想要的一切。

编者留言

这位小姐姐是真的很厉害啦，凭借努力拿到了百度等多家大厂的offer，现就职于字节。大家也是一样，不管性别家庭，只要肯努力，总有一天，你会得到自己想要的。既然决定去远方，那便无畏险阻，只管风雨兼程，付出总会有收获！我这里整理了一套学习资料，以及很多大厂的面试真题《Android架构视频+BATZ面试专题PDF+学习笔记》，希望能帮助大家早日圆大厂的梦，拿到心仪的offer。