當前位置：首頁 >

Git之常见的分支操作

發布時間：2025/3/19 34 豆豆

生活随笔收集整理的這篇文章主要介紹了 Git之常见的分支操作小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

分支管理

分支就是科幻電影里面的平行宇宙，當你正在電腦前努力學習Git的時候，另一個你正在另一個平行宇宙里努力學習SVN。

如果兩個平行宇宙互不干擾，那對現在的你也沒啥影響。不過，在某個時間點，兩個平行宇宙合并了，結果，你既學會了Git又學會了SVN！

分支在實際中有什么用呢？假設你準備開發一個新功能，但是需要兩周才能完成，第一周你寫了50%的代碼，如果立刻提交，由于代碼還沒寫完，不完整的代碼庫會導致別人不能干活了。如果等代碼全部寫完再一次提交，又存在丟失每天進度的巨大風險。

現在有了分支，就不用怕了。你創建了一個屬于你自己的分支，別人看不到，還繼續在原來的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到開發完畢后，再一次性合并到原來的分支上，這樣，既安全，又不影響別人工作。

其他版本控制系統如SVN等都有分支管理，但是用過之后你會發現，這些版本控制系統創建和切換分支比蝸牛還慢，簡直讓人無法忍受，結果分支功能成了擺設，大家都不去用。

但Git的分支是與眾不同的，無論創建、切換和刪除分支，Git在1秒鐘之內就能完成！無論你的版本庫是1個文件還是1萬個文件。

1.創建與合并分支

在版本回退里，你已經知道，每次提交，Git都把它們串成一條時間線，這條時間線就是一個分支。截止到目前，只有一條時間線，在Git里，這個分支叫主分支，即master分支。HEAD嚴格來說不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是當前分支。

一開始的時候，master分支是一條線，Git用master指向最新的提交，再用HEAD指向master，就能確定當前分支，以及當前分支的提交點：

每次提交，master分支都會向前移動一步，這樣，隨著你不斷提交，master分支的線也越來越長。

當我們創建新的分支，例如dev時，Git新建了一個指針叫dev，指向master相同的提交，再把HEAD指向dev，就表示當前分支在dev上：

你看，Git創建一個分支很快，因為除了增加一個dev指針，改改HEAD的指向，工作區的文件都沒有任何變化！

不過，從現在開始，對工作區的修改和提交就是針對dev分支了，比如新提交一次后，dev指針往前移動一步，而master指針不變：

假如我們在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最簡單的方法，就是直接把master指向dev的當前提交，就完成了合并：

所以Git合并分支也很快！就改改指針，工作區內容也不變！

合并完分支后，甚至可以刪除dev分支。刪除dev分支就是把dev指針給刪掉，刪掉后，我們就剩下了一條master分支：

真是太神奇了，你看得出來有些提交是通過分支完成的嗎？

下面開始實戰。

首先，我們創建dev分支，然后切換到dev分支：

$ git checkout -b dev Switched to a new branch 'dev'

git checkout命令加上-b參數表示創建并切換，相當于以下兩條命令：

$ git branch dev $ git checkout dev Switched to branch 'dev'

然后，用git branch命令查看當前分支：

$ git branch * devmaster

git branch命令會列出所有分支，當前分支前面會標一個*號。

然后，我們就可以在dev分支上正常提交，比如對readme.txt做個修改，加上一行：

Creating a new branch is quick.

然后提交：

$ git add readme.txt $ git commit -m "branch test" [dev b17d20e] branch test1 file changed, 1 insertion(+)

現在，dev分支的工作完成，我們就可以切換回master分支：

$ git checkout master Switched to branch 'master'

切換回master分支后，再查看一個readme.txt文件，剛才添加的內容不見了！因為那個提交是在dev分支上，而master分支此刻的提交點并沒有變：

現在，我們把dev分支的工作成果合并到master分支上：

$ git merge dev Updating d46f35e..b17d20e Fast-forwardreadme.txt | 1 +1 file changed, 1 insertion(+)

git merge命令用于合并指定分支到當前分支。合并后，再查看readme.txt的內容，就可以看到，和dev分支的最新提交是完全一樣的。

$ cat read.TXT 只爭朝夕，不負韶華！ Git is a version control system. 世上無難事，只怕有心人我是MXS zx xjg 2020年6月17日

注意到上面的Fast-forward信息，Git告訴我們，這次合并是“快進模式”，也就是直接把master指向dev的當前提交，所以合并速度非常快。

當然，也不是每次合并都能Fast-forward，我們后面會講其他方式的合并。

合并完成后，就可以放心地刪除dev分支了：

$ git branch -d dev Deleted branch dev (was b17d20e).

刪除后，查看branch，就只剩下master分支了：

$ git branch * master

因為創建、合并和刪除分支非常快，所以Git鼓勵你使用分支完成某個任務，合并后再刪掉分支，這和直接在master分支上工作效果是一樣的，但過程更安全。

1.2switch

我們注意到切換分支使用git checkout <branch>，而前面講過的撤銷修改則是git checkout -- <file>，同一個命令，有兩種作用，確實有點令人迷惑。

實際上，切換分支這個動作，用switch更科學。因此，最新版本的Git提供了新的git switch命令來切換分支：

創建并切換到新的dev分支，可以使用：

$ git switch -c dev

直接切換到已有的master分支，可以使用：

$ git switch master

使用新的git switch命令，比git checkout要更容易理解。

2.解決沖突

人生不如意之事十之八九，合并分支往往也不是一帆風順的。

準備新的feature1分支，繼續我們的新分支開發：

$ git switch -c feature1 Switched to a new branch 'feature1'

修改readme.txt最后一行，改為：

Creating a new branch is quick AND simple.

在feature1分支上提交：

$ git add readme.txt$ git commit -m "AND simple" [feature1 14096d0] AND simple1 file changed, 1 insertion(+), 1 deletion(-)

切換到master分支：

$ git switch master Switched to branch 'master' Your branch is ahead of 'origin/master' by 1 commit.(use "git push" to publish your local commits)

Git還會自動提示我們當前master分支比遠程的master分支要超前1個提交。

在master分支上把readme.txt文件的最后一行改為：

Creating a new branch is quick & simple.

提交：

$ git add readme.txt $ git commit -m "& simple" [master 5dc6824] & simple1 file changed, 1 insertion(+), 1 deletion(-)

現在，master分支和feature1分支各自都分別有新的提交，變成了這樣：

這種情況下，Git無法執行“快速合并”，只能試圖把各自的修改合并起來，但這種合并就可能會有沖突，我們試試看：

$ git merge feature1 Auto-merging readme.txt CONFLICT (content): Merge conflict in readme.txt Automatic merge failed; fix conflicts and then commit the result.

果然沖突了！Git告訴我們，readme.txt文件存在沖突，必須手動解決沖突后再提交。git status也可以告訴我們沖突的文件：

$ git status On branch master Your branch is ahead of 'origin/master' by 2 commits.(use "git push" to publish your local commits)You have unmerged paths.(fix conflicts and run "git commit")(use "git merge --abort" to abort the merge)Unmerged paths:(use "git add <file>..." to mark resolution)both modified: readme.txtno changes added to commit (use "git add" and/or "git commit -a")

我們可以直接查看readme.txt的內容：

只爭朝夕，不負韶華！ Git is a version control system. 世上無難事，只怕有心人我是MXS zx xjg <<<<<<< HEAD 000 ======= 2020年6月17日 0000 >>>>>>> featurel

Git用<<<<<<<，=======，>>>>>>>標記出不同分支的內容，我們修改如下后保存：

2020年6月17日

再提交：

$ git add readme.txt $ git commit -m "conflict fixed" [master cf810e4] conflict fixed

現在，master分支和feature1分支變成了下圖所示：

用帶參數的git log也可以看到分支的合并情況：

$ git log --graph --pretty=oneline --abbrev-commit * 99fa0a0 (HEAD -> master) ccc |\ | * 5174635 (featurel) 8zx * | aa309c8 fff |/ * 06e428d (origin/master) remove love.TXT * 284196c git track * e0b6320 understand how stage works * a2092c9 3 * 747bea0 2 * e5b5712 1 * 021749f mxs * 34ec753 zx * af87

最后，刪除feature1分支：

$ git branch -d feature1 Deleted branch feature1 (was 14096d0).

3.分支管理策略

通常，合并分支時，如果可能，Git會用Fast forward模式，但這種模式下，刪除分支后，會丟掉分支信息。

如果要強制禁用Fast forward模式，Git就會在merge時生成一個新的commit，這樣，從分支歷史上就可以看出分支信息。

下面我們實戰一下--no-ff方式的git merge：

首先，仍然創建并切換dev分支：

$ git switch -c dev Switched to a new branch 'dev'

修改readme.txt文件，并提交一個新的commit：

$ git add readme.txt $ git commit -m "add merge" [dev f52c633] add merge1 file changed, 1 insertion(+)

現在，我們切換回master：

$ git switch master Switched to branch 'master'

準備合并dev分支，請注意--no-ff參數，表示禁用Fast forward：

$ git merge --no-ff -m "merge with no-ff" dev Merge made by the 'recursive' strategy.readme.txt | 1 +1 file changed, 1 insertion(+)

因為本次合并要創建一個新的commit，所以加上-m參數，把commit描述寫進去。

合并后，我們用git log看看分支歷史：

$ git log --graph --pretty=oneline --abbrev-commit * e1e9c68 (HEAD -> master) merge with no-ff |\ | * f52c633 (dev) add merge |/ * cf810e4 conflict fixed ...

可以看到，不使用Fast forward模式，merge后就像這樣：

4.分支策略

在實際開發中，我們應該按照幾個基本原則進行分支管理：

首先，master分支應該是非常穩定的，也就是僅用來發布新版本，平時不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是說，dev分支是不穩定的，到某個時候，比如1.0版本發布時，再把dev分支合并到master上，在master分支發布1.0版本；

你和你的小伙伴們每個人都在dev分支上干活，每個人都有自己的分支，時不時地往dev分支上合并就可以了。

所以，團隊合作的分支看起來就像這樣：

5.Bug分支

軟件開發中，bug就像家常便飯一樣。有了bug就需要修復，在Git中，由于分支是如此的強大，所以，每個bug都可以通過一個新的臨時分支來修復，修復后，合并分支，然后將臨時分支刪除。

當你接到一個修復一個代號101的bug的任務時，很自然地，你想創建一個分支issue-101來修復它，但是，等等，當前正在dev上進行的工作還沒有提交：

$ git status On branch dev Changes to be committed:(use "git reset HEAD <file>..." to unstage)new file: hello.pyChanges not staged for commit:(use "git add <file>..." to update what will be committed)(use "git checkout -- <file>..." to discard changes in working directory)modified: readme.txt

并不是你不想提交，而是工作只進行到一半，還沒法提交，預計完成還需1天時間。但是，必須在兩個小時內修復該bug，怎么辦？

幸好，Git還提供了一個stash功能，可以把當前工作現場“儲藏”起來，等以后恢復現場后繼續工作：

$ git stash Saved working directory and index state WIP on dev: f52c633 add merge

現在，用git status查看工作區，就是干凈的（除非有沒有被Git管理的文件），因此可以放心地創建分支來修復bug。

首先確定要在哪個分支上修復bug，假定需要在master分支上修復，就從master創建臨時分支：

$ git checkout master Switched to branch 'master' Your branch is ahead of 'origin/master' by 6 commits.(use "git push" to publish your local commits)$ git checkout -b issue-101 Switched to a new branch 'issue-101'

現在修復bug，需要把“000.”改為“00”，然后提交：

$ git add readme.txt $ git commit -m "fix bug 101" [issue-101 4c805e2] fix bug 1011 file changed, 1 insertion(+), 1 deletion(-)

修復完成后，切換到master分支，并完成合并，最后刪除issue-101分支：

$ git switch master Switched to branch 'master' Your branch is ahead of 'origin/master' by 6 commits.(use "git push" to publish your local commits)$ git merge --no-ff -m "merged bug fix 101" issue-101 Merge made by the 'recursive' strategy.readme.txt | 2 +-1 file changed, 1 insertion(+), 1 deletion(-)

太棒了，原計劃兩個小時的bug修復只花了5分鐘！現在，是時候接著回到dev分支干活了！

$ git switch dev Switched to branch 'dev'$ git status On branch dev nothing to commit, working tree clean

工作區是干凈的，剛才的工作現場存到哪去了？用git stash list命令看看：

$ git stash list stash@{0}: WIP on dev: f52c633 add merge

工作現場還在，Git把stash內容存在某個地方了，但是需要恢復一下，有兩個辦法：

一是用git stash apply恢復，但是恢復后，stash內容并不刪除，你需要用git stash drop來刪除；

另一種方式是用git stash pop，恢復的同時把stash內容也刪了：

$ git stash pop On branch dev Changes to be committed:(use "git reset HEAD <file>..." to unstage)new file: hello.pyChanges not staged for commit:(use "git add <file>..." to update what will be committed)(use "git checkout -- <file>..." to discard changes in working directory)modified: readme.txtDropped refs/stash@{0} (5d677e2ee266f39ea296182fb2354265b91b3b2a)

再用git stash list查看，就看不到任何stash內容了：

$ git stash list

你可以多次stash，恢復的時候，先用git stash list查看，然后恢復指定的stash，用命令：

$ git stash apply stash@{0}

在master分支上修復了bug后，我們要想一想，dev分支是早期從master分支分出來的，所以，這個bug其實在當前dev分支上也存在。

那怎么在dev分支上修復同樣的bug？重復操作一次，提交不就行了？

有木有更簡單的方法？

有！

同樣的bug，要在dev上修復，我們只需要把4c805e2 fix bug 101這個提交所做的修改“復制”到dev分支。注意：我們只想復制4c805e2 fix bug 101這個提交所做的修改，并不是把整個master分支merge過來。

為了方便操作，Git專門提供了一個cherry-pick命令，讓我們能復制一個特定的提交到當前分支：

$ git branch * devmaster $ git cherry-pick 4c805e2 [master 1d4b803] fix bug 1011 file changed, 1 insertion(+), 1 deletion(-)

Git自動給dev分支做了一次提交，注意這次提交的commit是1d4b803，它并不同于master的4c805e2，因為這兩個commit只是改動相同，但確實是兩個不同的commit。用git cherry-pick，我們就不需要在dev分支上手動再把修bug的過程重復一遍。

有些聰明的童鞋會想了，既然可以在master分支上修復bug后，在dev分支上可以“重放”這個修復過程，那么直接在dev分支上修復bug，然后在master分支上“重放”行不行？當然可以，不過你仍然需要git stash命令保存現場，才能從dev分支切換到master分支。

6.Feature分支

軟件開發中，總有無窮無盡的新的功能要不斷添加進來。

添加一個新功能時，你肯定不希望因為一些實驗性質的代碼，把主分支搞亂了，所以，每添加一個新功能，最好新建一個feature分支，在上面開發，完成后，合并，最后，刪除該feature分支。

現在，你終于接到了一個新任務：開發代號為Vulcan的新功能，該功能計劃用于下一代星際飛船。

于是準備開發：

$ git switch -c feature-vulcan Switched to a new branch 'feature-vulcan'

5分鐘后，開發完畢：

$ git add vulcan.py$ git status On branch feature-vulcan Changes to be committed:(use "git reset HEAD <file>..." to unstage)new file: vulcan.py$ git commit -m "add feature vulcan" [feature-vulcan 287773e] add feature vulcan1 file changed, 2 insertions(+)create mode 100644 vulcan.py

切回dev，準備合并：

$ git switch dev

一切順利的話，feature分支和bug分支是類似的，合并，然后刪除。

但是！

就在此時，接到上級命令，因經費不足，新功能必須取消！

雖然白干了，但是這個包含機密資料的分支還是必須就地銷毀：

$ git branch -d feature-vulcan error: The branch 'feature-vulcan' is not fully merged. If you are sure you want to delete it, run 'git branch -D feature-vulcan'.

銷毀失敗。Git友情提醒，feature-vulcan分支還沒有被合并，如果刪除，將丟失掉修改，如果要強行刪除，需要使用大寫的-D參數。。

現在我們強行刪除：

$ git branch -D feature-vulcan Deleted branch feature-vulcan (was 287773e).

終于刪除成功！

7.多人協作

當你從遠程倉庫克隆時，實際上Git自動把本地的master分支和遠程的master分支對應起來了，并且，遠程倉庫的默認名稱是origin。

要查看遠程庫的信息，用git remote：

$ git remote origin

或者，用git remote -v顯示更詳細的信息：

$ git remote -v origin https://github.com/ITmxs/mygit.git (fetch) origin https://github.com/ITmxs/mygit.git (push)

上面顯示了可以抓取和推送的origin的地址。如果沒有推送權限，就看不到push的地址。

8.推送分支

推送分支，就是把該分支上的所有本地提交推送到遠程庫。推送時，要指定本地分支，這樣，Git就會把該分支推送到遠程庫對應的遠程分支上：

$ git push origin master

如果要推送其他分支，比如dev，就改成：

$ git push origin dev

但是，并不是一定要把本地分支往遠程推送，那么，哪些分支需要推送，哪些不需要呢？

master分支是主分支，因此要時刻與遠程同步；
dev分支是開發分支，團隊所有成員都需要在上面工作，所以也需要與遠程同步；
bug分支只用于在本地修復bug，就沒必要推到遠程了，除非老板要看看你每周到底修復了幾個bug；
feature分支是否推到遠程，取決于你是否和你的小伙伴合作在上面開發。

總之，就是在Git中，分支完全可以在本地自己藏著玩，是否推送，視你的心情而定！

9.抓取分支

多人協作時，大家都會往master和dev分支上推送各自的修改。

現在，模擬一個你的小伙伴，可以在另一臺電腦（注意要把SSH Key添加到GitHub）或者同一臺電腦的另一個目錄下克隆：

$ git clone git@github.com:michaelliao/learngit.git Cloning into 'learngit'... remote: Counting objects: 40, done. remote: Compressing objects: 100% (21/21), done. remote: Total 40 (delta 14), reused 40 (delta 14), pack-reused 0 Receiving objects: 100% (40/40), done. Resolving deltas: 100% (14/14), done.

當你的小伙伴從遠程庫clone時，默認情況下，你的小伙伴只能看到本地的master分支。不信可以用git branch命令看看：

$ git branch * master

現在，你的小伙伴要在dev分支上開發，就必須創建遠程origin的dev分支到本地，于是他用這個命令創建本地dev分支：

$ git checkout -b dev origin/dev

現在，他就可以在dev上繼續修改，然后，時不時地把dev分支push到遠程：

$ git add env.txt$ git commit -m "add env" [dev 7a5e5dd] add env1 file changed, 1 insertion(+)create mode 100644 env.txt$ git push origin dev Counting objects: 3, done. Delta compression using up to 4 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 308 bytes | 308.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0) To github.com:michaelliao/learngit.gitf52c633..7a5e5dd dev -> dev

你的小伙伴已經向origin/dev分支推送了他的提交，而碰巧你也對同樣的文件作了修改，并試圖推送：

$ cat env.txt env$ git add env.txt$ git commit -m "add new env" [dev 7bd91f1] add new env1 file changed, 1 insertion(+)create mode 100644 env.txt$ git push origin dev To github.com:michaelliao/learngit.git! [rejected] dev -> dev (non-fast-forward) error: failed to push some refs to 'git@github.com:michaelliao/learngit.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Integrate the remote changes (e.g. hint: 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.

推送失敗，因為你的小伙伴的最新提交和你試圖推送的提交有沖突，解決辦法也很簡單，Git已經提示我們，先用git pull把最新的提交從origin/dev抓下來，然后，在本地合并，解決沖突，再推送：

$ git pull There is no tracking information for the current branch. Please specify which branch you want to merge with. See git-pull(1) for details.git pull <remote> <branch>If you wish to set tracking information for this branch you can do so with:git branch --set-upstream-to=origin/<branch> dev

git pull也失敗了，原因是沒有指定本地dev分支與遠程origin/dev分支的鏈接，根據提示，設置dev和origin/dev的鏈接：

$ git branch --set-upstream-to=origin/dev dev Branch 'dev' set up to track remote branch 'dev' from 'origin'.

再pull：

$ git pull Auto-merging env.txt CONFLICT (add/add): Merge conflict in env.txt Automatic merge failed; fix conflicts and then commit the result.

這回git pull成功，但是合并有沖突，需要手動解決，解決的方法和分支管理中的解決沖突完全一樣。解決后，提交，再push

$ git commit -m "fix env conflict" [dev 57c53ab] fix env conflict$ git push origin dev Counting objects: 6, done. Delta compression using up to 4 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (6/6), 621 bytes | 621.00 KiB/s, done. Total 6 (delta 0), reused 0 (delta 0) To github.com:michaelliao/learngit.git7a5e5dd..57c53ab dev -> dev

因此，多人協作的工作模式通常是這樣：

首先，可以試圖用git push origin <branch-name>推送自己的修改；

如果推送失敗，則因為遠程分支比你的本地更新，需要先用git pull試圖合并；

如果合并有沖突，則解決沖突，并在本地提交；

沒有沖突或者解決掉沖突后，再用git push origin <branch-name>推送就能成功！

如果git pull提示no tracking information，則說明本地分支和遠程分支的鏈接關系沒有創建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。

這就是多人協作的工作模式，一旦熟悉了，就非常簡單。

10.Rebase（變基）

在上一節我們看到了，多人在同一個分支上協作時，很容易出現沖突。即使沒有沖突，后push的童鞋不得不先pull，在本地合并，然后才能push成功。

每次合并再push后，分支變成了這樣：

$ git log --graph --pretty=oneline --abbrev-commit * d1be385 (HEAD -> master, origin/master) init hello * e5e69f1 Merge branch 'dev' |\ | * 57c53ab (origin/dev, dev) fix env conflict | |\ | | * 7a5e5dd add env | * | 7bd91f1 add new env | |/ * | 12a631b merged bug fix 101 |\ \ | * | 4c805e2 fix bug 101 |/ / * | e1e9c68 merge with no-ff |\ \ | |/ | * f52c633 add merge |/ * cf810e4 conflict fixed

總之看上去很亂，有強迫癥的童鞋會問：為什么Git的提交歷史不能是一條干凈的直線？

其實是可以做到的！

Git有一種稱為rebase的操作，有人把它翻譯成“變基”。

先不要隨意展開想象。我們還是從實際問題出發，看看怎么把分叉的提交變成直線。

在和遠程分支同步后，我們對hello.py這個文件做了兩次提交。用git log命令看看：

$ git log --graph --pretty=oneline --abbrev-commit * 582d922 (HEAD -> master) add author * 8875536 add comment * d1be385 (origin/master) init hello * e5e69f1 Merge branch 'dev' |\ | * 57c53ab (origin/dev, dev) fix env conflict | |\ | | * 7a5e5dd add env | * | 7bd91f1 add new env ...

注意到Git用(HEAD -> master)和(origin/master)標識出當前分支的HEAD和遠程origin的位置分別是582d922 add author和d1be385 init hello，本地分支比遠程分支快兩個提交。

現在我們嘗試推送本地分支：

$ git push origin master To github.com:michaelliao/learngit.git! [rejected] master -> master (fetch first) error: failed to push some refs to 'git@github.com:michaelliao/learngit.git' hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes hint: (e.g., 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.

很不幸，失敗了，這說明有人先于我們推送了遠程分支。按照經驗，先pull一下：

$ git pull remote: Counting objects: 3, done. remote: Compressing objects: 100% (1/1), done. remote: Total 3 (delta 1), reused 3 (delta 1), pack-reused 0 Unpacking objects: 100% (3/3), done. From github.com:michaelliao/learngitd1be385..f005ed4 master -> origin/master* [new tag] v1.0 -> v1.0 Auto-merging hello.py Merge made by the 'recursive' strategy.hello.py | 1 +1 file changed, 1 insertion(+)

再用git status看看狀態：

$ git status On branch master Your branch is ahead of 'origin/master' by 3 commits.(use "git push" to publish your local commits)nothing to commit, working tree clean

加上剛才合并的提交，現在我們本地分支比遠程分支超前3個提交。

用git log看看：

對強迫癥童鞋來說，現在事情有點不對頭，提交歷史分叉了。如果現在把本地分支push到遠程，有沒有問題？

有！

什么問題？

不好看！

有沒有解決方法？

有！

這個時候，rebase就派上了用場。我們輸入命令git rebase試試：

$ git rebase First, rewinding head to replay your work on top of it... Applying: add comment Using index info to reconstruct a base tree... M hello.py Falling back to patching base and 3-way merge... Auto-merging hello.py Applying: add author Using index info to reconstruct a base tree... M hello.py Falling back to patching base and 3-way merge... Auto-merging hello.py

輸出了一大堆操作，到底是啥效果？再用git log看看：

$ git log --graph --pretty=oneline --abbrev-commit * 7e61ed4 (HEAD -> master) add author * 3611cfe add comment * f005ed4 (origin/master) set exit=1 * d1be385 init hello ...

原本分叉的提交現在變成一條直線了！這種神奇的操作是怎么實現的？其實原理非常簡單。我們注意觀察，發現Git把我們本地的提交“挪動”了位置，放到了f005ed4 (origin/master) set exit=1之后，這樣，整個提交歷史就成了一條直線。rebase操作前后，最終的提交內容是一致的，但是，我們本地的commit修改內容已經變化了，它們的修改不再基于d1be385 init hello，而是基于f005ed4 (origin/master) set exit=1，但最后的提交7e61ed4內容是一致的。

這就是rebase操作的特點：把分叉的提交歷史“整理”成一條直線，看上去更直觀。缺點是本地的分叉提交已經被修改過了。

最后，通過push操作把本地分支推送到遠程：

$ git push origin master Counting objects: 6, done. Delta compression using up to 4 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (6/6), 576 bytes | 576.00 KiB/s, done. Total 6 (delta 2), reused 0 (delta 0) remote: Resolving deltas: 100% (2/2), completed with 1 local object. To github.com:michaelliao/learngit.gitf005ed4..7e61ed4 master -> master

再用git log看看效果：

$ git log --graph --pretty=oneline --abbrev-commit * 7e61ed4 (HEAD -> master, origin/master) add author * 3611cfe add comment * f005ed4 set exit=1 * d1be385 init hello ...

這種神奇的操作是怎么實現的？其實原理非常簡單。我們注意觀察，發現Git把我們本地的提交“挪動”了位置，放到了f005ed4 (origin/master) set exit=1之后，這樣，整個提交歷史就成了一條直線。rebase操作前后，最終的提交內容是一致的，但是，我們本地的commit修改內容已經變化了，它們的修改不再基于d1be385 init hello，而是基于f005ed4 (origin/master) set exit=1，但最后的提交7e61ed4內容是一致的。