Git实用指南第三篇

本篇提要:Rebase

第三天:Rebase的传说

路人丙是个有探索精神的人,虽然昨天通过分支+cherry-pick成功解决了问题,但他总觉得有些怪异,哪里怪异又具体说不上来。哦,大概是这样的问题,既然要摘取竹节再安在上边,我能不能直接在我的竹子上操作,而不是在副本操作呢?就像这样:

最上面两节是我新做的竹子,等我要合并时发现了飞机酱的竹节,我就先把这两节取下来,把飞机酱的安上去,最后再把取下来的安回去:

如此一来,不就不需要副本了吗。但问题是,怎么才能达到这个目的呢?路人丙想起来曾经和飞机酱聊过Rebase的传说。传闻Rebase神通广大,有神鬼莫测之术,但如果使用它的人实力不够强大,会因为无法完全控制产生灾难性的后果,最后不得不删库跑路。

越是如此,路人丙对它的兴趣越大,赶紧查了资料,不禁看得入迷,越发无法控制(不好,难道这玩意还能摄人心智?)。不得不说,Rebase的确强大,拿来做这件事绰绰有余啊。今天飞机酱请假了,刚好可以自由发挥,等他回来好好炫耀一波。

也许是兴奋吧,今天路人丙超常发挥,做了三节竹子!但是要尝试新方法,非得飞机酱配合不可,没有他的工作记录我和谁rebase呀。哎,谁让我人好呢,这最后一节竹子就送给你吧,希望你以后能念我的好。路人丙先是把第三节竹节安在了飞机酱的竹子上,并在他的电脑里做好了记录(当然先pull下昨天的工作)。

先加暂存区,再到版本库,然后同步到公共电脑一气呵成。做完这一切赶紧在自己的电脑上试验,这一次他并没有直接pull,而是在后边追加了 --rebase:

git pull --rebase
image.png

然而奇迹并没有发生,原来路人丙太兴奋了,送竹节的记录连文件名都没改,直接全套交给飞机酱了。不过merge时出现冲突,好像没有这么长的提示呀(rebase果然不是那么好降服的),原来rebase解决完冲突是 git add + git rebase --continue ,而不是像merge时 git add + git commit -m了。然后路人丙按照提示,去解决冲突:

看起来和merge没什么区别,但是怎么只有我的一条记录呢,我的第二节竹子去哪了?(心中默念,rebase这么强大,肯定不会有问题的)先解决一下再说吧:

// 先解决冲突,然后add
git add .
git rebase --continue

原来如此,rebase时是一条一条commit进行了,第一条有了冲突,所以需要解决,解决好之后发现第二条没有冲突,就直接合好了。推到远端看看记录:

简直完美,以后再也不需要先在副本上干,再挪回来了。得此技能,我应该已经甩飞机酱十八条街了。不过这里有个小小的瑕疵,让我们快退回去rebase之前的状态:

这是路人丙当时的工作记录,把目光盯紧在那串commitId上,让我们再rebase一次,仔细看commitId的变化:

也就是不管有没有冲突,commitId都变了。就像cherry-pick一样,虽然工作记录看起来整洁,但是真实的操作记录都丢失了。看来万事万物没有完美的,就算强如rebase,也有其做不到的事情呀。

前情回顾

Git实用指南第二篇


我是飞机酱,如果您喜欢我的文章,可以关注我~

编程之路,道阻且长。唯,路漫漫其修远兮,吾将上下而求索。

你可能感兴趣的:(Git实用指南第三篇)