當多人協作開發乙個分支時，歷史記錄通常如下方左圖所示，比較凌亂。如果希望能像右圖那樣呈線性提交，就需要學習git rebase的用法。
我們的工作流程是：修改**→提交到本地倉庫→拉取遠端改動→推送。正是在git pull這一步產生的merge branch提交。事實上，git pull等效於get fetch origin和get merge origin/master這兩條命令，前者是拉取遠端倉庫到本地臨時庫，後者是將臨時庫中的改動合併到本地分支中。
要避免merge branch提交也有乙個「土法」：先pull、再commit、最後push。不過萬一commit和push之間遠端又發生了改動，還需要再pull一次，就又會產生merge branch提交。
修改**→commit→git pull –rebase→git push。也就是將get merge origin/master替換成了git rebase origin/master，它的過程是先將head指向origin/master，然後逐一應用本地的修改，這樣就不會產生merge branch提交了。具體過程見下文擴充套件閱讀。
使用git rebase是有條件的，你的本地倉庫要「足夠乾淨」。可以用git status命令檢視當前改動：：
$ git status
on branch master
your branch is up-to-date
with
'origin/master'.
nothing
to commit, working directory clean
$ git status
on branch master
your branch is up-to-date
with
'origin/master'.
untracked files:
(use "git add ..."
toinclude
in what will be committed)
test.txt
nothing added to commit but untracked files present (use "git add"
to track)
每次都加–rebase似乎有些麻煩，我們可以指定某個分支在執行git pull時預設採用rebase方式：
$ git config branch.master.rebase true$
gitconfig--
global
branch
.autosetuprebase
always
先看看git merge的示意圖：
可以看到some feature分支的兩個提交通過乙個新的提交（藍色）和master連線起來了。
再來看git rebase的示意圖：
feature分支中的兩個提交被「嫁接」到了master分支的頭部，或者說feature分支的「基」（base）變成了 master，rebase也因此得名。
在做專案開發時會用到分支，合併時採用以下步驟：
$ git checkout feature-branch
$ git rebase master
$ git checkout master
$ git merge --no-ff feature-branch
$ git push origin master
可以看到，merge branch 『feature-branch』那段可以很好的展現出這些提交是屬於某一特性的。
git rebase修改歷史提交
如果執行了一系列提交後，想修改其中不是最近的某幾次提交，可以執行 git rebase i 然後在要修改的那幾次提交前面改為edit 儲存推出後，git會按順序逐一提示要修改的提交，這時就可以按順序修改這些提交，修改完後分別執行git add 和git commit amend git rebase...
git rebase使用記錄
git rebase 最常用的操作有兩個 1 變基 本地dev分支修改 commit後發現遠端分支已經有了新的修改，此時需要git pull dev再git push推送到遠端，此時的提交記錄會出現分叉並多一次合併，如果使用git rebase dev會將本地提交的commit放到最新的遠端分支的提...
git rebase 使用詳解
假設你現在基於遠端分支 origin 建立乙個叫 mywork 的分支。現在我們在這個分支做一些修改，然後生成兩個提交 commit vi file.txt git commit vi otherfile.txt git commit 但是與此同時，有些人也在 origin 分支上做了一些修改並且做...