git rebase，顧名思義，就是重新定義（re）起點（base）的作用，即重新定義分支的版本庫狀態。要搞清楚這個東西，要先看看版本庫狀態切換的兩種情況：
我們知道，在某個分支上，我們可以通過git reset，實現將當前分支切換到本分支以前的任何乙個版本狀態，即所謂的「回溯」。即實現了本分支的「後悔藥」。也即版本控制系統的初衷。
還有另一種情況，當我們的專案有多個分支的時候。我們除了在本地開發的時候可能會「回溯」外，也常常會將和自己並行開發的別人的分支修改新增到自 己本地來。這種情況下很常見。作為專案管理員，肯定會不斷的合併各個子專案的補丁，並將最新版本推送到公共版本庫，而作為開發人員之一，提交自己的補丁之 後，往往需要將自己的工作更新到最新的版本庫，也就是說把別的分支的工作包含進來。
舉個例子來說吧！假設我們的專案初期只有乙個master分支，然後分支上作過兩次提交。這個時候系統只有乙個master分支，他的分支歷史如下：
master0（初始化後的版本）||v這個時候，我們可以通過git reset將master分支（工作目錄、工作快取或者是版本庫）切換到master1或者master0版本，這就是前面所說的第一種情況。master1（第一次提交後的版本）||v
master2（第二次提交後的版本）
假設我們這裡把master分支通過git reset回溯到了master1狀態。那麼這個時候系統仍然只有乙個master分支，分支的歷史如下：
master0（初始化後的版本）||v然後，我們在這裡以master1為起點，建立了另乙個分支test。那麼對於test分支來說，他的第乙個版本test0就和master1是同乙個版本，此時專案的分支歷史如下：master1（第一次提交後的版本）
master0（初始化後的版本）||v這個時候，我們分別對master分支、test分支作兩次提交，此時版本庫應該成了這個樣子：master1（第一次提交後的版本）===test0（test分支，初始化自master分支master1狀態）
master0（初始化後的版本）||v這個時候，通過第一種git reset的方式，可以將master分支的當前狀態（master3）回溯到master分支的master0、master1、master2狀態。 也可已將test分支當前狀態（test2）回溯到test分支的test0、test1狀態，以及test分支的父分支master的master0、 master1狀態。master1===test0==>test1===>test2||v
master2===>master3
那麼。如果我要讓test分支從test0到test2之間所有的改變都新增到master分支來，使得master分支包含test分支的所有修改。這個時候就要用到git rebase了。
首先，我們切換到master分支，然後執行下面的命令，即可實現我們的要求：
1
gitrebasetest
這個時候，git做了些什麼呢？
先將test分支的**checkout出來，作為工作目錄
然後將master分支從test分支建立起的所有改變的補丁，依次打上。如果打補丁的過程沒問題，rebase就搞定了
如果打補丁的時候出現了問題，就會提示你處理衝突。處理好了，可以執行git rebase –continue繼續直到完成
如果你不想處理，你還是有兩個選擇，乙個是放棄rebase過程（執行git rebase –abort），另乙個是直接用test分支的取代當前分支的（git rebase –skip）。
git中merge和rebase的區別
最開始實習的時候是使用svn，之後正式工作就一直在使用git，這樣算起來，使用git也有兩年的時間了。以前帶我的同事，讓我在拉 的時候要我使用git pull rebase，一直很納悶為什麼要那樣做，後來遇到拉 的時候有許多衝突要解決，然後去查詢資料，才了解到其中的一些事情。今天分享一下，順便自己也...
git的使用中，merge與rebase的區別
一致在使用git，感覺git好多功能，有很多功能也沒有搞清楚，特別是merge和rebase到底是啥區別，一直沒搞明白，網上很多介紹，很多官方套話，說的模稜兩可，今天看了一位仁兄的介紹，寫的還算是比較清晰，拿過來備份下來，也方便大家學習。1 以下的研討基礎 假設我們有如下圖一所示倉庫，該倉庫有mas...
Git 設定自動rebase
1.設定所有分支自動rebasegit config branch.autosetuprebase always 或者git config global branch.autosetuprebase always此時宿主目錄下的.gitconfig檔案會多出下面的內容 branch autosetu...