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