Git Rebase教程： 用Git Rebase讓時光倒流
想象一下你正在開發(fā)一個激進的新功能。這將是很燦爛的但它需要一段時間。您這幾天也許是幾個星期一直在做這個。
你的功能分支已經(jīng)超前master有6個提交了。你是一個優(yōu)秀的開發(fā)人員并做了有意義的語義提交。但有一件事情：你開始慢慢意識到，這個瘋狂的東西仍需要更多的時間才能真的做好準備被合并回主分支。
- m1-m2-m3-m4 (master)
- \
- f1-f2-f3-f4-f5-f6(feature)
你也知道的是，一些地方實際上是交叉不大的新功能。它們可以更早地合并到主分支。不幸的是，你想將部分合并到主分支的內(nèi)容存在于你六個提交中的某個 地方。更糟糕的是，它也包含了依賴于你的功能分支的之前的提交。有人可能會說，你應(yīng)該在***處地方做兩次提交，但沒有人是***的。
- m1-m2-m3-m4 (master)
- \
- f1-f2-f3-f4-f5-f6(feature)
- ^
- |
- mixed commit
在你準備提交的時間，你沒有預見到，你可能要逐步把該功能合并入主分支。哎呀！你不會想到這件事會有這么久。
你需要的是一種方法可以回溯歷史，把它并分成兩次提交，這樣就可以把代碼都安全地分離出來，并可以移植到master分支。
用圖說話，就是我們需要這樣。
- m1-m2-m3-m4 (master)
- \
- f1-f2-f3a-f3b-f4-f5-f6(feature)
在將工作分成兩個提交后，我們就可以cherry-pick出前面的部分到主分支了。
原來Git自帶了一個功能強大的命令git rebase -i ，它可以讓我們這樣做。它可以讓我們改變歷史。改變歷史可能會產(chǎn)生問題，作為一個經(jīng)驗，應(yīng)盡快避免歷史與他人共享。不過在我們的例子中，我們只是改變我們 的本地功能分支的歷史。沒有人會受到傷害。就這么做了！
好吧，讓我們來仔細看看f3提交究竟修改了什么。原來我們共修改了兩個文件：userService.js和 wishlistService.js。比方說，userService.js的更改可以直接合入主分支而wishlistService.js不能。因 為wishlistService.js甚至不存在在主分支里面。它是f1提交中引入的。
專家提示：即使是在一個文件中更改，git也可以搞定。但這篇博客中我們先簡化情況。
我們已經(jīng)建立了一個公眾演示倉庫，我們將使用這個來練習。為了便于跟蹤，每一個提交信息的前綴是在上面的圖表中使用的假的SHA。以下是git在分開提交f3時的分支圖。
現(xiàn)在，我們要做的***件事就是使用git的checkout功能checkout出我們的功能分支。用git rebase -i master開始做rebase。
現(xiàn)在接下來git會用所配置的編輯器打開（默認為Vim）一個臨時文件。
該文件為您提供一些rebase選擇，它帶有一個提示（藍色文字）。對于每一個提交，我們可以選擇的動作有pick、rwork、edit、 squash、fixup和exec。每一個動作也可以通過它的縮寫形式p、r、e、s、f和e引用。描述每一個選項超出了本文范疇，所以讓我們專注于我 們的具體任務(wù)。
我們要為f3提交選擇edit選項，因此我們把內(nèi)容改變成這樣。
現(xiàn)在我們保存文件（在Vim中是按下后輸入:wq,***是按下回車）。接下來我們注意到git在編輯選項中選擇的提交處停止了rebase。
這意味這git開始將f1、f2、f3生效仿佛它就是常規(guī)的rebase，但是在f3生效之后停止。事實上，我們可以看一眼停止的地方的日志就可以證明這一點。
要將f3分成兩個提交，我們所要做的是重置git的指針到先前的提交（f2）而保持工作目錄和現(xiàn)在一樣。這就是git reset在混合模式在做的。由于混合模式是git reset的默認模式，我們可以直接用git reset head~1。就這么做并在運行后用git status看下發(fā)生了什么。
git status告訴我們userService.js和wishlistService.js被修改了。如果我們運行 git diff 我們就可以看見在f3里面確切地做了哪些更改。
如果我們看一眼日志我們會發(fā)現(xiàn)f3已經(jīng)消失了。
現(xiàn)在我們有了準備提交的先前的f3提交，而原先的f3提交已經(jīng)消失了。記住雖然我們?nèi)耘f在rebase的中間過程。我們的f4、f5、f6提交還沒有缺失，它們會在接下來回來。
讓我們創(chuàng)建兩個新的提交：首先讓我們?yōu)榭梢蕴峤坏街鞣种У膗serService.js創(chuàng)建一個提交。運行g(shù)it add userService.js 接著運行 git commit -m "f3a: add updateUser method"。
太棒了！讓我們?yōu)閣ishlistService.js的改變創(chuàng)建另外一個提交。運行g(shù)it add wishlistService.js，接著運行g(shù)it commit -m "f3b: add addItems method".
讓我們在看一眼日志。
這就是我們想要的，除了f4、f5、f6仍舊缺失。這是因為我們?nèi)栽趓ebase交互的中間，我們需要告訴git繼續(xù)rebase。用下面的命令繼續(xù)：git rebase --continue。
讓我們再次檢查一下日志。
就是這樣。我們現(xiàn)在已經(jīng)得到我們想要的歷史了。先前的f3提交現(xiàn)在已經(jīng)被分割成兩個提交f3a和f3b。剩下的***一件事是cherry-pick出f3a提交到主分支上。
為了完成***一步，我們首先切換到主分支。我們用git checkout master。現(xiàn)在我們就可以用cherry-pick命令來拾取f3a commit了。本例中我們可以用它的SHA值bd47ee1來引用它。
現(xiàn)在f3a這個提交就在主分支的最上面了。這就是我們需要的！
這篇文章的長度看起來需要花費很大的功夫，但實際上對于一個git高級用戶而言這只是一會會。
注：Christoph目前正在與Pascal Precht寫一本關(guān)于Git rebase的書，您可以在leanpub訂閱它并在準備出版時獲得通知。
本文作者 Christoph Burgdorf自10歲時就是一名程序員，他是HannoverJS Meetup網(wǎng)站的創(chuàng)始人，并且一直活躍在AngularJS社區(qū)。他也是非常了解gti的內(nèi)內(nèi)外外，在那里他舉辦一個thoughtram的工作室來幫助初學者掌握該技術(shù)。
本的教程最初發(fā)表在他的blog。
via: https://www.codementor.io/git-tutorial/git-rebase-split-old-commit-master
