目錄

• • • 分支管理
    • • 1.創(chuàng)建與合并分支
      • • 1.2switch
      • 2.解決沖突
      • 3.分支管理策略
      • 4.分支策略
      • 5.Bug分支
      • 6.Feature分支
      • 7.多人協(xié)作
      • 8.推送分支
      • 9.抓取分支
      • 10.Rebase（變基）

分支管理

分支就是科幻電影里面的平行宇宙，當(dāng)你正在電腦前努力學(xué)習(xí)Git的時(shí)候，另一個(gè)你正在另一個(gè)平行宇宙里努力學(xué)習(xí)SVN。

如果兩個(gè)平行宇宙互不干擾，那對(duì)現(xiàn)在的你也沒(méi)啥影響。不過(guò)，在某個(gè)時(shí)間點(diǎn)，兩個(gè)平行宇宙合并了，結(jié)果，你既學(xué)會(huì)了Git又學(xué)會(huì)了SVN！

分支在實(shí)際中有什么用呢？假設(shè)你準(zhǔn)備開(kāi)發(fā)一個(gè)新功能，但是需要兩周才能完成，第一周你寫(xiě)了50%的代碼，如果立刻提交，由于代碼還沒(méi)寫(xiě)完，不完整的代碼庫(kù)會(huì)導(dǎo)致別人不能干活了。如果等代碼全部寫(xiě)完再一次提交，又存在丟失每天進(jìn)度的巨大風(fēng)險(xiǎn)。

現(xiàn)在有了分支，就不用怕了。你創(chuàng)建了一個(gè)屬于你自己的分支，別人看不到，還繼續(xù)在原來(lái)的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到開(kāi)發(fā)完畢后，再一次性合并到原來(lái)的分支上，這樣，既安全，又不影響別人工作。

其他版本控制系統(tǒng)如SVN等都有分支管理，但是用過(guò)之后你會(huì)發(fā)現(xiàn)，這些版本控制系統(tǒng)創(chuàng)建和切換分支比蝸牛還慢，簡(jiǎn)直讓人無(wú)法忍受，結(jié)果分支功能成了擺設(shè)，大家都不去用。

但Git的分支是與眾不同的，無(wú)論創(chuàng)建、切換和刪除分支，Git在1秒鐘之內(nèi)就能完成！無(wú)論你的版本庫(kù)是1個(gè)文件還是1萬(wàn)個(gè)文件。

1.創(chuàng)建與合并分支

在版本回退里，你已經(jīng)知道，每次提交，Git都把它們串成一條時(shí)間線，這條時(shí)間線就是一個(gè)分支。截止到目前，只有一條時(shí)間線，在Git里，這個(gè)分支叫主分支，即master分支。HEAD嚴(yán)格來(lái)說(shuō)不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是當(dāng)前分支。

一開(kāi)始的時(shí)候，master分支是一條線，Git用master指向最新的提交，再用HEAD指向master，就能確定當(dāng)前分支，以及當(dāng)前分支的提交點(diǎn)：

每次提交，master分支都會(huì)向前移動(dòng)一步，這樣，隨著你不斷提交，master分支的線也越來(lái)越長(zhǎng)。

當(dāng)我們創(chuàng)建新的分支，例如dev時(shí)，Git新建了一個(gè)指針叫dev，指向master相同的提交，再把HEAD指向dev，就表示當(dāng)前分支在dev上：

你看，Git創(chuàng)建一個(gè)分支很快，因?yàn)槌嗽黾右粋€(gè)dev指針，改改HEAD的指向，工作區(qū)的文件都沒(méi)有任何變化！

不過(guò)，從現(xiàn)在開(kāi)始，對(duì)工作區(qū)的修改和提交就是針對(duì)dev分支了，比如新提交一次后，dev指針往前移動(dòng)一步，而master指針不變：

假如我們?cè)赿ev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最簡(jiǎn)單的方法，就是直接把master指向dev的當(dāng)前提交，就完成了合并：

所以Git合并分支也很快！就改改指針，工作區(qū)內(nèi)容也不變！

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

真是太神奇了，你看得出來(lái)有些提交是通過(guò)分支完成的嗎？

下面開(kāi)始實(shí)戰(zhàn)。

首先，我們創(chuàng)建dev分支，然后切換到dev分支：

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

git checkout命令加上-b參數(shù)表示創(chuàng)建并切換，相當(dāng)于以下兩條命令：

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

然后，用git branch命令查看當(dāng)前分支：

$ git branch * devmaster

git branch命令會(huì)列出所有分支，當(dāng)前分支前面會(huì)標(biāo)一個(gè)*號(hào)。

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

Creating a new branch is quick.

然后提交：

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

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

$ git checkout master Switched to branch 'master'

切換回master分支后，再查看一個(gè)readme.txt文件，剛才添加的內(nèi)容不見(jiàn)了！因?yàn)槟莻€(gè)提交是在dev分支上，而master分支此刻的提交點(diǎn)并沒(méi)有變：

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

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

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

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

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

當(dāng)然，也不是每次合并都能Fast-forward，我們后面會(huì)講其他方式的合并。

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

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

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

$ git branch * master

因?yàn)閯?chuàng)建、合并和刪除分支非常快，所以Git鼓勵(lì)你使用分支完成某個(gè)任務(wù)，合并后再刪掉分支，這和直接在master分支上工作效果是一樣的，但過(guò)程更安全。

1.2switch

我們注意到切換分支使用git checkout <branch>，而前面講過(guò)的撤銷(xiāo)修改則是git checkout -- <file>，同一個(gè)命令，有兩種作用，確實(shí)有點(diǎn)令人迷惑。

實(shí)際上，切換分支這個(gè)動(dòng)作，用switch更科學(xué)。因此，最新版本的Git提供了新的git switch命令來(lái)切換分支：

創(chuàng)建并切換到新的dev分支，可以使用：

$ git switch -c dev

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

$ git switch master

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

2.解決沖突

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

準(zhǔn)備新的feature1分支，繼續(xù)我們的新分支開(kāi)發(fā)：

$ 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還會(huì)自動(dòng)提示我們當(dāng)前master分支比遠(yuǎn)程的master分支要超前1個(gè)提交。

在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(-)

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

這種情況下，Git無(wú)法執(zhí)行“快速合并”，只能試圖把各自的修改合并起來(lái)，但這種合并就可能會(huì)有沖突，我們?cè)囋嚳?#xff1a;

$ 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文件存在沖突，必須手動(dòng)解決沖突后再提交。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的內(nèi)容：

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

Git用<<<<<<<，=======，>>>>>>>標(biāo)記出不同分支的內(nèi)容，我們修改如下后保存：

2020年6月17日

再提交：

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

現(xiàn)在，master分支和feature1分支變成了下圖所示：

用帶參數(shù)的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.分支管理策略

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

如果要強(qiáng)制禁用Fast forward模式，Git就會(huì)在merge時(shí)生成一個(gè)新的commit，這樣，從分支歷史上就可以看出分支信息。

下面我們實(shí)戰(zhàn)一下--no-ff方式的git merge：

首先，仍然創(chuàng)建并切換dev分支：

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

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

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

現(xiàn)在，我們切換回master：

$ git switch master Switched to branch 'master'

準(zhǔn)備合并dev分支，請(qǐng)注意--no-ff參數(shù)，表示禁用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(+)

因?yàn)楸敬魏喜⒁獎(jiǎng)?chuàng)建一個(gè)新的commit，所以加上-m參數(shù)，把commit描述寫(xiě)進(jìn)去。

合并后，我們用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.分支策略

在實(shí)際開(kāi)發(fā)中，我們應(yīng)該按照幾個(gè)基本原則進(jìn)行分支管理：

首先，master分支應(yīng)該是非常穩(wěn)定的，也就是僅用來(lái)發(fā)布新版本，平時(shí)不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是說(shuō)，dev分支是不穩(wěn)定的，到某個(gè)時(shí)候，比如1.0版本發(fā)布時(shí)，再把dev分支合并到master上，在master分支發(fā)布1.0版本；

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

所以，團(tuán)隊(duì)合作的分支看起來(lái)就像這樣：

5.Bug分支

軟件開(kāi)發(fā)中，bug就像家常便飯一樣。有了bug就需要修復(fù)，在Git中，由于分支是如此的強(qiáng)大，所以，每個(gè)bug都可以通過(guò)一個(gè)新的臨時(shí)分支來(lái)修復(fù)，修復(fù)后，合并分支，然后將臨時(shí)分支刪除。

當(dāng)你接到一個(gè)修復(fù)一個(gè)代號(hào)101的bug的任務(wù)時(shí)，很自然地，你想創(chuàng)建一個(gè)分支issue-101來(lái)修復(fù)它，但是，等等，當(dāng)前正在dev上進(jìn)行的工作還沒(méi)有提交：

$ 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

并不是你不想提交，而是工作只進(jìn)行到一半，還沒(méi)法提交，預(yù)計(jì)完成還需1天時(shí)間。但是，必須在兩個(gè)小時(shí)內(nèi)修復(fù)該bug，怎么辦？

幸好，Git還提供了一個(gè)stash功能，可以把當(dāng)前工作現(xiàn)場(chǎng)“儲(chǔ)藏”起來(lái)，等以后恢復(fù)現(xiàn)場(chǎng)后繼續(xù)工作：

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

現(xiàn)在，用git status查看工作區(qū)，就是干凈的（除非有沒(méi)有被Git管理的文件），因此可以放心地創(chuàng)建分支來(lái)修復(fù)bug。

首先確定要在哪個(gè)分支上修復(fù)bug，假定需要在master分支上修復(fù)，就從master創(chuàng)建臨時(shí)分支：

$ 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'

現(xiàn)在修復(fù)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(-)

修復(fù)完成后，切換到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(-)

太棒了，原計(jì)劃兩個(gè)小時(shí)的bug修復(fù)只花了5分鐘！現(xiàn)在，是時(shí)候接著回到dev分支干活了！

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

工作區(qū)是干凈的，剛才的工作現(xiàn)場(chǎng)存到哪去了？用git stash list命令看看：

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

工作現(xiàn)場(chǎng)還在，Git把stash內(nèi)容存在某個(gè)地方了，但是需要恢復(fù)一下，有兩個(gè)辦法：

一是用git stash apply恢復(fù)，但是恢復(fù)后，stash內(nèi)容并不刪除，你需要用git stash drop來(lái)刪除；

另一種方式是用git stash pop，恢復(fù)的同時(shí)把stash內(nèi)容也刪了：

$ 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內(nèi)容了：

$ git stash list

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

$ git stash apply stash@{0}

在master分支上修復(fù)了bug后，我們要想一想，dev分支是早期從master分支分出來(lái)的，所以，這個(gè)bug其實(shí)在當(dāng)前dev分支上也存在。

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

有木有更簡(jiǎn)單的方法？

有！

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

為了方便操作，Git專(zhuān)門(mén)提供了一個(gè)cherry-pick命令，讓我們能復(fù)制一個(gè)特定的提交到當(dāng)前分支：

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

Git自動(dòng)給dev分支做了一次提交，注意這次提交的commit是1d4b803，它并不同于master的4c805e2，因?yàn)檫@兩個(gè)commit只是改動(dòng)相同，但確實(shí)是兩個(gè)不同的commit。用git cherry-pick，我們就不需要在dev分支上手動(dòng)再把修bug的過(guò)程重復(fù)一遍。

有些聰明的童鞋會(huì)想了，既然可以在master分支上修復(fù)bug后，在dev分支上可以“重放”這個(gè)修復(fù)過(guò)程，那么直接在dev分支上修復(fù)bug，然后在master分支上“重放”行不行？當(dāng)然可以，不過(guò)你仍然需要git stash命令保存現(xiàn)場(chǎng)，才能從dev分支切換到master分支。

6.Feature分支

軟件開(kāi)發(fā)中，總有無(wú)窮無(wú)盡的新的功能要不斷添加進(jìn)來(lái)。

添加一個(gè)新功能時(shí)，你肯定不希望因?yàn)橐恍?shí)驗(yàn)性質(zhì)的代碼，把主分支搞亂了，所以，每添加一個(gè)新功能，最好新建一個(gè)feature分支，在上面開(kāi)發(fā)，完成后，合并，最后，刪除該feature分支。

現(xiàn)在，你終于接到了一個(gè)新任務(wù)：開(kāi)發(fā)代號(hào)為Vulcan的新功能，該功能計(jì)劃用于下一代星際飛船。

于是準(zhǔn)備開(kāi)發(fā)：

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

5分鐘后，開(kāi)發(fā)完畢：

$ 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，準(zhǔn)備合并：

$ git switch dev

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

但是！

就在此時(shí)，接到上級(jí)命令，因經(jīng)費(fèi)不足，新功能必須取消！

雖然白干了，但是這個(gè)包含機(jī)密資料的分支還是必須就地銷(xiāo)毀：

$ 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'.

銷(xiāo)毀失敗。Git友情提醒，feature-vulcan分支還沒(méi)有被合并，如果刪除，將丟失掉修改，如果要強(qiáng)行刪除，需要使用大寫(xiě)的-D參數(shù)。。

現(xiàn)在我們強(qiáng)行刪除：

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

終于刪除成功！

7.多人協(xié)作

當(dāng)你從遠(yuǎn)程倉(cāng)庫(kù)克隆時(shí)，實(shí)際上Git自動(dòng)把本地的master分支和遠(yuǎn)程的master分支對(duì)應(yīng)起來(lái)了，并且，遠(yuǎn)程倉(cāng)庫(kù)的默認(rèn)名稱是origin。

要查看遠(yuǎn)程庫(kù)的信息，用git remote：

$ git remote origin

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

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

上面顯示了可以抓取和推送的origin的地址。如果沒(méi)有推送權(quán)限，就看不到push的地址。

8.推送分支

推送分支，就是把該分支上的所有本地提交推送到遠(yuǎn)程庫(kù)。推送時(shí)，要指定本地分支，這樣，Git就會(huì)把該分支推送到遠(yuǎn)程庫(kù)對(duì)應(yīng)的遠(yuǎn)程分支上：

$ git push origin master

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

$ git push origin dev

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

• master分支是主分支，因此要時(shí)刻與遠(yuǎn)程同步；
• dev分支是開(kāi)發(fā)分支，團(tuán)隊(duì)所有成員都需要在上面工作，所以也需要與遠(yuǎn)程同步；
• bug分支只用于在本地修復(fù)bug，就沒(méi)必要推到遠(yuǎn)程了，除非老板要看看你每周到底修復(fù)了幾個(gè)bug；
• feature分支是否推到遠(yuǎn)程，取決于你是否和你的小伙伴合作在上面開(kāi)發(fā)。

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

9.抓取分支

多人協(xié)作時(shí)，大家都會(huì)往master和dev分支上推送各自的修改。

現(xiàn)在，模擬一個(gè)你的小伙伴，可以在另一臺(tái)電腦（注意要把SSH Key添加到GitHub）或者同一臺(tái)電腦的另一個(gè)目錄下克隆：

$ 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.

當(dāng)你的小伙伴從遠(yuǎn)程庫(kù)clone時(shí)，默認(rèn)情況下，你的小伙伴只能看到本地的master分支。不信可以用git branch命令看看：

$ git branch * master

現(xiàn)在，你的小伙伴要在dev分支上開(kāi)發(fā)，就必須創(chuàng)建遠(yuǎn)程origin的dev分支到本地，于是他用這個(gè)命令創(chuàng)建本地dev分支：

$ git checkout -b dev origin/dev

現(xiàn)在，他就可以在dev上繼續(xù)修改，然后，時(shí)不時(shí)地把dev分支push到遠(yuǎn)程：

$ 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

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

$ 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.

推送失敗，因?yàn)槟愕男』锇榈淖钚绿峤缓湍阍噲D推送的提交有沖突，解決辦法也很簡(jiǎn)單，Git已經(jīng)提示我們，先用git pull把最新的提交從origin/dev抓下來(lái)，然后，在本地合并，解決沖突，再推送：

$ 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也失敗了，原因是沒(méi)有指定本地dev分支與遠(yuǎn)程origin/dev分支的鏈接，根據(jù)提示，設(shè)置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成功，但是合并有沖突，需要手動(dòng)解決，解決的方法和分支管理中的解決沖突完全一樣。解決后，提交，再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

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

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

如果推送失敗，則因?yàn)檫h(yuǎn)程分支比你的本地更新，需要先用git pull試圖合并；

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

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

如果git pull提示no tracking information，則說(shuō)明本地分支和遠(yuǎn)程分支的鏈接關(guān)系沒(méi)有創(chuàng)建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。

這就是多人協(xié)作的工作模式，一旦熟悉了，就非常簡(jiǎn)單。

10.Rebase（變基）

在上一節(jié)我們看到了，多人在同一個(gè)分支上協(xié)作時(shí)，很容易出現(xiàn)沖突。即使沒(méi)有沖突，后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

總之看上去很亂，有強(qiáng)迫癥的童鞋會(huì)問(wèn)：為什么Git的提交歷史不能是一條干凈的直線？

其實(shí)是可以做到的！

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

先不要隨意展開(kāi)想象。我們還是從實(shí)際問(wèn)題出發(fā)，看看怎么把分叉的提交變成直線。

在和遠(yuǎn)程分支同步后，我們對(duì)hello.py這個(gè)文件做了兩次提交。用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)標(biāo)識(shí)出當(dāng)前分支的HEAD和遠(yuǎn)程origin的位置分別是582d922 add author和d1be385 init hello，本地分支比遠(yuǎn)程分支快兩個(gè)提交。

現(xiàn)在我們嘗試推送本地分支：

$ 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.

很不幸，失敗了，這說(shuō)明有人先于我們推送了遠(yuǎn)程分支。按照經(jīng)驗(yàn)，先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看看狀態(tài)：

$ 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

加上剛才合并的提交，現(xiàn)在我們本地分支比遠(yuǎn)程分支超前3個(gè)提交。

用git log看看：

$ git log --graph --pretty=oneline --abbrev-commit * e0ea545 (HEAD -> master) Merge branch 'master' of github.com:michaelliao/learngit |\ | * f005ed4 (origin/master) set exit=1 * | 582d922 add author * | 8875536 add comment |/ * d1be385 init hello ...

對(duì)強(qiáng)迫癥童鞋來(lái)說(shuō)，現(xiàn)在事情有點(diǎn)不對(duì)頭，提交歷史分叉了。如果現(xiàn)在把本地分支push到遠(yuǎn)程，有沒(méi)有問(wèn)題？

有！

什么問(wèn)題？

不好看！

有沒(méi)有解決方法？

有！

這個(gè)時(shí)候，rebase就派上了用場(chǎng)。我們輸入命令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 ...

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

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

最后，通過(guò)push操作把本地分支推送到遠(yuǎn)程：

$ 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 ...

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

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

最后，通過(guò)push操作把本地分支推送到遠(yuǎn)程：

$ 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 ...

遠(yuǎn)程分支的提交歷史也是一條直線。

總結(jié)

以上是生活随笔為你收集整理的Git之常见的分支操作的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。