本篇提要：Rebase
第三天：Rebase的傳說
路人丙是個有探索精神的人，雖然昨天通過分支+cherry-pick成功解決了問題，但他總覺得有些怪異，哪里怪異又具體說不上來。哦，大概是這樣的問題，既然要摘取竹節(jié)再安在上邊，我能不能直接在我的竹子上操作，而不是在副本操作呢？就像這樣：
最上面兩節(jié)是我新做的竹子，等我要合并時發(fā)現(xiàn)了飛機醬的竹節(jié)，我就先把這兩節(jié)取下來，把飛機醬的安上去，最后再把取下來的安回去：
如此一來，不就不需要副本了嗎。但問題是，怎么才能達到這個目的呢？路人丙想起來曾經(jīng)和飛機醬聊過Rebase的傳說。傳聞Rebase神通廣大，有神鬼莫測之術(shù)，但如果使用它的人實力不夠強大，會因為無法完全控制產(chǎn)生災(zāi)難性的后果，最后不得不刪庫跑路。
越是如此，路人丙對它的興趣越大，趕緊查了資料，不禁看得入迷，越發(fā)無法控制（不好，難道這玩意還能攝人心智？）。不得不說，Rebase的確強大，拿來做這件事綽綽有余啊。今天飛機醬請假了，剛好可以自由發(fā)揮，等他回來好好炫耀一波。
也許是興奮吧，今天路人丙超常發(fā)揮，做了三節(jié)竹子！但是要嘗試新方法，非得飛機醬配合不可，沒有他的工作記錄我和誰rebase呀。哎，誰讓我人好呢，這最后一節(jié)竹子就送給你吧，希望你以后能念我的好。路人丙先是把第三節(jié)竹節(jié)安在了飛機醬的竹子上，并在他的電腦里做好了記錄（當(dāng)然先pull下昨天的工作）。
先加暫存區(qū)，再到版本庫，然后同步到公共電腦一氣呵成。做完這一切趕緊在自己的電腦上試驗，這一次他并沒有直接pull，而是在后邊追加了 --rebase:
git pull --rebase
然而奇跡并沒有發(fā)生，原來路人丙太興奮了，送竹節(jié)的記錄連文件名都沒改，直接全套交給飛機醬了。不過merge時出現(xiàn)沖突，好像沒有這么長的提示呀（rebase果然不是那么好降服的），原來rebase解決完沖突是 git add + git rebase --continue ，而不是像merge時 git add + git commit -m了。然后路人丙按照提示，去解決沖突：
看起來和merge沒什么區(qū)別，但是怎么只有我的一條記錄呢，我的第二節(jié)竹子去哪了？（心中默念，rebase這么強大，肯定不會有問題的）先解決一下再說吧：
// 先解決沖突，然后add
git add .
git rebase --continue
原來如此，rebase時是一條一條commit進行了，第一條有了沖突，所以需要解決，解決好之后發(fā)現(xiàn)第二條沒有沖突，就直接合好了。推到遠端看看記錄：
簡直完美，以后再也不需要先在副本上干，再挪回來了。得此技能，我應(yīng)該已經(jīng)甩飛機醬十八條街了。不過這里有個小小的瑕疵，讓我們快退回去rebase之前的狀態(tài)：
這是路人丙當(dāng)時的工作記錄，把目光盯緊在那串commitId上，讓我們再rebase一次，仔細看commitId的變化：
也就是不管有沒有沖突，commitId都變了。就像cherry-pick一樣，雖然工作記錄看起來整潔，但是真實的操作記錄都丟失了?？磥砣f事萬物沒有完美的，就算強如rebase，也有其做不到的事情呀。
前情回顧
我是飛機醬，如果您喜歡我的文章，可以關(guān)注我~
編程之路，道阻且長。唯，路漫漫其修遠兮，吾將上下而求索。
