分支的新建與合并

讓我們來看一個簡單的分支新建與分支合并的例子，實際工作中你可能會用到類似的工作流。

你將經歷如下步驟：

開發某個網站。

為實現某個新的需求，創建一個分支。

在這個分支上開展工作。

正在此時，你突然接到一個電話說有個很嚴重的問題需要緊急修補。

你將按照如下方式來處理：

切換到你的線上分支（production branch）。

為這個緊急任務新建一個分支，并在其中修復它。

在測試通過之后，切換回線上分支，然后合并這個修補分支，最后將改動推送到線上分支。

切換回你最初工作的分支上，繼續工作。

新建分支

首先，我們假設你正在你的項目上工作，并且已經有一些提交。

Figure 18. 一個簡單提交歷史

現在，你已經決定要解決你的公司使用的問題追蹤系統中的 #53 問題。想要新建一個分支并同時切換到那個分支上，你可以運行一個帶有-b參數的git checkout命令：

$ git checkout -b iss53

Switched to a new branch "iss53"

它是下面兩條命令的簡寫：

$ git branch iss53

$ git checkout iss53

Figure 19. 創建一個新分支指針

你繼續在 #53 問題上工作，并且做了一些提交。在此過程中，iss53分支在不斷的向前推進，因為你已經檢出到該分支（也就是說，你的HEAD指針指向了iss53分支）

$ vim index.html

$ git commit -a -m 'added a new footer [issue 53]'

Figure 20. iss53 分支隨著工作的進展向前推進

現在你接到那個電話，有個緊急問題等待你來解決。有了 Git 的幫助，你不必把這個緊急問題和iss53的修改混在一起，你也不需要花大力氣來還原關于 53# 問題的修改，然后再添加關于這個緊急問題的修改，最后將這個修改提交到線上分支。你所要做的僅僅是切換回master分支。

但是，在你這么做之前，要留意你的工作目錄和暫存區里那些還沒有被提交的修改，它可能會和你即將檢出的分支產生沖突從而阻止 Git 切換到該分支。最好的方法是，在你切換分支之前，保持好一個干凈的狀態。有一些方法可以繞過這個問題（即，保存進度（stashing） 和 修補提交（commit amending）），我們會在儲藏與清理中看到關于這兩個命令的介紹。現在，我們假設你已經把你的修改全部提交了，這時你可以切換回master分支了：

$ git checkout master

Switched to branch 'master'

這個時候，你的工作目錄和你在開始 #53 問題之前一模一樣，現在你可以專心修復緊急問題了。

請牢記：當你切換分支的時候，Git 會重置你的工作目錄，使其看起來像回到了你在那個分支上最后一次提交的樣子。

Git 會自動添加、刪除、修改文件以確保此時你的工作目錄和這個分支最后一次提交時的樣子一模一樣。

接下來，你要修復這個緊急問題。

讓我們建立一個針對該緊急問題的分支（hotfix branch），在該分支上工作直到問題解決：

$ git checkout -b hotfix

Switched to a new branch 'hotfix'

$ vim index.html

$ git commit -a -m 'fixed the broken email address'

[hotfix 1fb7853] fixed the broken email address

1 file changed, 2 insertions(+)

Figure 21. 基于master分支的緊急問題分支hotfix branch

你可以運行你的測試，確保你的修改是正確的，然后將其合并回你的master分支來部署到線上。你可以使用git merge命令來達到上述目的：

$ git checkout master

$ git merge hotfix

Updating f42c576..3a0874c

Fast-forward

index.html | 2 ++

1 file changed, 2 insertions(+)

在合并的時候，你應該注意到了"快進（fast-forward）"這個詞。由于當前master分支所指向的提交是你當前提交（有關 hotfix 的提交）的直接上游，所以 Git 只是簡單的將指針向前移動。換句話說，當你試圖合并兩個分支時，如果順著一個分支走下去能夠到達另一個分支，那么 Git 在合并兩者的時候，只會簡單的將指針向前推進（指針右移），因為這種情況下的合并操作沒有需要解決的分歧——這就叫做 “快進（fast-forward）”。

現在，最新的修改已經在master分支所指向的提交快照中，你可以著手發布該修復了。

Figure 22.master被快進到hotfix

關于這個緊急問題的解決方案發布之后，你準備回到被打斷之前時的工作中。然而，你應該先刪除hotfix分支，因為你已經不再需要它了 ——master分支已經指向了同一個位置。你可以使用帶-d選項的git branch命令來刪除分支：

$ git branch -d hotfix

Deleted branch hotfix (3a0874c).

現在你可以切換回你正在工作的分支繼續你的工作，也就是針對 #53 問題的那個分支（iss53 分支）。

$ git checkout iss53

Switched to branch "iss53"

$ vim index.html

$ git commit -a -m 'finished the new footer [issue 53]'

[iss53 ad82d7a] finished the new footer [issue 53]

1 file changed, 1 insertion(+)

Figure 23. 繼續在iss53分支上的工作

你在hotfix分支上所做的工作并沒有包含到iss53分支中。如果你需要拉取hotfix所做的修改，你可以使用git merge master命令將master分支合并入iss53分支，或者你也可以等到iss53分支完成其使命，再將其合并回master分支。

分支的合并

假設你已經修正了 #53 問題，并且打算將你的工作合并入master分支。為此，你需要合并iss53分支到master分支，這和之前你合并hotfix分支所做的工作差不多。你只需要檢出到你想合并入的分支，然后運行git merge命令：

$ git checkout master

Switched to branch 'master'

$ git merge iss53

Merge made by the 'recursive' strategy.

index.html |? ? 1 +

1 file changed, 1 insertion(+)

這和你之前合并hotfix分支的時候看起來有一點不一樣。在這種情況下，你的開發歷史從一個更早的地方開始分叉開來（diverged）。因為，master分支所在提交并不是iss53分支所在提交的直接祖先，Git 不得不做一些額外的工作。出現這種情況的時候，Git 會使用兩個分支的末端所指的快照（C4和C5）以及這兩個分支的工作祖先（C2），做一個簡單的三方合并。

Figure 24. 一次典型合并中所用到的三個快照

和之前將分支指針向前推進所不同的是，Git 將此次三方合并的結果做了一個新的快照并且自動創建一個新的提交指向它。

這個被稱作一次合并提交，它的特別之處在于他有不止一個父提交。

Figure 25. 一個合并提交

需要指出的是，Git 會自行決定選取哪一個提交作為最優的共同祖先，并以此作為合并的基礎；這和更加古老的 CVS 系統或者 Subversion （1.5 版本之前）不同，在這些古老的版本管理系統中，用戶需要自己選擇最佳的合并基礎。

Git 的這個優勢使其在合并操作上比其他系統要簡單很多。

既然你的修改已經合并進來了，你已經不再需要iss53分支了。現在你可以在任務追蹤系統中關閉此項任務，并刪除這個分支。

$ git branch -d iss53

遇到沖突時的分支合并

有時候合并操作不會如此順利。如果你在兩個不同的分支中，對同一個文件的同一個部分進行了不同的修改，Git 就沒法干凈的合并它們。如果你對 #53 問題的修改和有關hotfix的修改都涉及到同一個文件的同一處，在合并它們的時候就會產生合并沖突：

$ git merge iss53

Auto-merging index.html

CONFLICT (content): Merge conflict in index.html

Automatic merge failed; fix conflicts and then commit the result.

此時 Git 做了合并，但是沒有自動地創建一個新的合并提交。Git 會暫停下來，等待你去解決合并產生的沖突。你可以在合并沖突后的任意時刻使用git status命令來查看那些因包含合并沖突而處于未合并（unmerged）狀態的文件：

$ git status

On branch master

You have unmerged paths.

(fix conflicts and run "git commit")

Unmerged paths:

(use "git add ..." to mark resolution)

both modified:? ? ? index.html

no changes added to commit (use "git add" and/or "git commit -a")

任何因包含合并沖突而有待解決的文件，都會以未合并狀態標識出來。

Git 會在有沖突的文件中加入標準的沖突解決標記，這樣你可以打開這些包含沖突的文件然后手動解決沖突。

出現沖突的文件會包含一些特殊區段，看起來像下面這個樣子：

<<<<<<< HEAD:index.html

=======

please contact us at support@github.com

>>>>>>> iss53:index.html

這表示HEAD所指示的版本（也就是你的master分支所在的位置，因為你在運行 merge 命令的時候已經檢出到了這個分支）在這個區段的上半部分（=======的上半部分），而iss53分支所指示的版本在=======的下半部分。為了解決沖突，你必須選擇使用由=======分割的兩部分中的一個，或者你也可以自行合并這些內容。例如，你可以通過把這段內容換成下面的樣子來解決沖突：

please contact us at email.support@github.com

上述的沖突解決方案僅保留了其中一個分支的修改，并且<<<<<<<,=======, 和>>>>>>>這些行被完全刪除了。在你解決了所有文件里的沖突之后，對每個文件使用git add命令來將其標記為沖突已解決。一旦暫存這些原本有沖突的文件，Git 就會將它們標記為沖突已解決。

如果你想使用圖形化工具來解決沖突，你可以運行git mergetool，該命令會為你啟動一個合適的可視化合并工具，并帶領你一步一步解決這些沖突：

$ git mergetool

This message is displayed because 'merge.tool' is not configured.

See 'git mergetool --tool-help' or 'git help config' for more details.

'git mergetool' will now attempt to use one of the following tools:

opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge

Merging:

index.html

Normal merge conflict for 'index.html':

{local}: modified file

{remote}: modified file

Hit return to start merge resolution tool (opendiff):

如果你想使用除默認工具（在這里 Git 使用opendiff做為默認的合并工具，因為作者在 Mac 上運行該程序）外的其他合并工具，你可以在 “下列工具中（one of the following tools）” 這句后面看到所有支持的合并工具。然后輸入你喜歡的工具名字就可以了。

Note

如果你需要更加高級的工具來解決復雜的合并沖突，我們會在高級合并介紹更多關于分支合并的內容。

等你退出合并工具之后，Git 會詢問剛才的合并是否成功。如果你回答是，Git 會暫存那些文件以表明沖突已解決：你可以再次運行git status來確認所有的合并沖突都已被解決：

$ git status

On branch master

All conflicts fixed but you are still merging.

(use "git commit" to conclude merge)

Changes to be committed:

modified:? index.html

如果你對結果感到滿意，并且確定之前有沖突的的文件都已經暫存了，這時你可以輸入git commit來完成合并提交。默認情況下提交信息看起來像下面這個樣子：

Merge branch 'iss53'

Conflicts:

index.html

#

# It looks like you may be committing a merge.

# If this is not correct, please remove the file

# .git/MERGE_HEAD

# and try again.

# Please enter the commit message for your changes. Lines starting

# with '#' will be ignored, and an empty message aborts the commit.

# On branch master

# All conflicts fixed but you are still merging.

#

# Changes to be committed:

# modified:? index.html

#

如果你覺得上述的信息不夠充分，不能完全體現分支合并的過程，你可以修改上述信息，添加一些細節給未來檢視這個合并的讀者一些幫助，告訴他們你是如何解決合并沖突的，以及理由是什么。