聊下 git rebase -i

在使用git開發的時候經常會面臨一個常見的問題。多個commit 需要合并為一個完整的commit提交。

我們先說第一個合并多個commit為一個完整的commit

我先基于develop主分支拉出一個功能分支（每個人和每個公司對分支的管理都不太一樣，這里不需要太糾結。）。這里的develop是開發主分支，所有的開發功能代碼都需要回歸到這個develop分支中去。

git branch -a –vv

develop_fixbug_p_w_picpathprint 分支是我基于遠程develop分支拉出來的開發分支，我會基于這個分支來fix一些bug。我們分別看下develop、develop_fixbug_p_w_picpathprint  commit log。

git checkout develop

git  log

git checkout develop_fixbug_p_w_picpathprint

git log

develop_fixbug_p_w_picpathprint的commit log是和devleop commit log 一模一樣。我們現在切換到develop_fixbug_p_w_picpathprint進行一些操作。

添加一個1.txt文件，然后git add . ，git commit –m’add 1.txt’。

再添加一個2.txt 文件，然后git add . ，git commit –m’add 2.txt’。    

現在develop_fixbug_p_w_picpathprint分支里有兩個commit。這兩個commit都是為了fix當前這個bug而做的兩個提交。現在我們要合并代碼上主develop分支。總不能把這兩個commit直接提交上去，這里還好只有兩個commit，但是一般項目開發周期兩個星期的話，你起碼有十幾個commit。那這樣提交上去之后就很難管理和跟蹤。（我以前都是這樣干的，現在發現這樣不好跟蹤管理。）

那么我們如何完成這個合并commit尼，就需要用到git rebase 命令。

先來解釋下git rebase 。你其實可以把它理解成是“重新設置基線”，將你的當前分支重新設置開始點。這個時候才能知道你當前分支于你需要比較的分支之間的差異。

比如，develop_fixbug_p_w_picpathprint分支是來自develop分支，那么從test commit開始后面我們基本上都是各自發展，現在在develop_fixbug_p_w_picpathprint分支上有兩個commit，我們需要找一個基準，這個基準就是git需要找到哪些是你后來提交的commmit，總的有個參照。

git reabse –i develop

git rebase 立馬知道develop與develop_fixbug_p_w_picpathprint之間的差異。因為我們是基于develop設置rebase的。git rebase –i ，這里的”-i“是指交互模式。就是說你可以干預rebase這個事務的過程，包括設置commit message，暫停commit等等。

這里我們要求很簡單就是合并之前的commit且重新設置commit message。

我們設置第二個”pick 657a291 add 2.txt” 為” s 657a291 add 2.txt”這里的s就是squash命令的簡寫。

跳出來了一個臨時文件，最上面是兩行commit message。我們修改下這個總體的commit message。

刪除之前的兩條message(ESC dd)，設置一總的message 然后保存退出。(ESC wq)

我們查看下log。git log

是不是沒有了之前的兩個commit。

原理很簡單：rebase需要基于一個分支來設置你當前的分支的基線，這基線就是當前分支的開始時間軸向后移動到最新的跟蹤分支的最后面，這樣你的當前分支就是最新的跟蹤分支。這里的操作是基于文件事務處理的，所以你不用怕中間失敗會影響文件的一致性。在中間的過程中你可以隨時取消rebase 事務。git rebase –abort

在進入git rebase –i 交互模式，你可以做的事情就很多了，可以設置edit 編輯commit 內容，可以讓他暫停commit操作。等等。