聊下 git rebase -i

在使用git做爲源代碼管理工具的時候，開發的時常常會面臨一個常見的問題，多個commit 須要合併爲一個完整的commit提交。

在一個基本的迭代週期裏，你會有不少次commit，有跟配置文件相關的，有跟代碼相關的，甚至有跟下次發佈fixbug相關的。這些都是你在完成本地開發的時候一個變化記錄而已。可是當你須要將你的迭代項目做爲一次發佈提交時就須要整合全部以前提交的那些很零碎的commit。

根據基本規範，你的commit應該相似"release：20161023_imageprint"，在此commit裏應該是完整的提交。

合併多個commit爲一個完整的commit

我先基於develop主分支拉出一個功能分支（每一個人和每一個公司對分支的管理都不太同樣，這裏不須要太糾結。）。這裏的develop是開發主分支，全部的開發功能代碼都須要迴歸到這個develop分支中去。

git branch -a –vv

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

git checkout develop

git  log

git checkout develop_fixbug_imageprint

git log

develop_fixbug_imageprint的commit log是和devleop commit log 如出一轍。咱們如今切換到develop_fixbug_imageprint進行一些操做。

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

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

如今develop_fixbug_imageprint分支裏有兩個commit。這兩個commit都是爲了fix當前這個bug而作的兩個提交。如今咱們要合併代碼上主develop分支。總不能把這兩個commit直接提交上去，這裏還好只有兩個commit，可是通常項目開發週期兩個星期的話，你起碼有十幾個commit。那這樣提交上去以後就很難管理和跟蹤。（我之前都是這樣乾的，如今發現這樣很差跟蹤管理。）

那麼咱們如何完成這個合併commit尼，就須要用到git rebase 命令。

先來解釋下git rebase 。你其實能夠把它理解成是「從新設置基線」，將你的當前分支從新設置開始點。這個時候才能知道你當前分支於你須要比較的分支之間的差別。

好比，develop_fixbug_imageprint分支是來自develop分支，那麼從test commit開始後面咱們基本上都是各自發展，如今在develop_fixbug_imageprint分支上有兩個commit，咱們須要找一個基準，這個基準就是git須要找到哪些是你後來提交的commmit，總的有個參照。

git reabse –i develop

git rebase 立馬知道develop與develop_fixbug_imageprint之間的差別。由於咱們是基於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操做。等等。