文章目录
-
- 写在前面
- 怎么用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能给项目开发带来极大的便利。
必定要好好学习，好好使用呀～
最终说句题外话，罗志祥的事轰轰烈烈，再次改写了我对渣男的认知。我想跟一切程序媛包括处于科技行业领域的女人说一句：
请自立自强，你的技术和才能决议你的高度；请不要为任何一个男人低头，由于你值得具有你想要的一切。
