在使用git作為源代碼管理工具的時候，開發的時經常會面臨一個常見的問題，多個commit 需要合并為一個完整的commit送出。
在一個基本的疊代周期裡，你會有很多次commit，有跟配置檔案相關的，有跟代碼相關的，甚至有跟下次釋出fixbug相關的。這些都是你在完成本地開發的時候一個變化記錄而已。但是當你需要将你的疊代項目作為一次釋出送出時就需要整合所有之前送出的那些很零碎的commit。
根據基本規範，你的commit應該類似"release：20161023_imageprint"，在此commit裡應該是完整的送出。
git branch -a –vv
合并多個commit為一個完整的commit
我先基于develop主分支拉出一個功能分支（每個人和每個公司對分支的管理都不太一樣，這裡不需要太糾結。）。這裡的develop是開發主分支，所有的開發功能代碼都需要回歸到這個develop分支中去。
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操作。等等。