3.2 Git 分支 - 分支的新建與合併
分支的新建與合併
讓我們來看一個簡單的分支新建與分支合併的例子，實際工作中你可能會用到類似的工作流。你將經歷如下步驟：
開發某個網站。
爲實現某個新的需求，創建一個分支。
在這個分支上開展工作。
正在此時，你突然接到一個電話說有個很嚴重的問題需要緊急修補。你將按照如下方式來處理：
切換到你的線上分支（production branch）。
爲這個緊急任務新建一個分支，並在其中修復它。
在測試通過之後，切換回線上分支，然後合併這個修補分支，最後將改動推送到線上分支。
切換回你最初工作的分支上，繼續工作。
新建分支
首先，我們假設你正在你的項目上工作，並且已經有一些提交。
現在，你已經決定要解決你的公司使用的問題追蹤系統中的 #53 問題。想要新建一個分支並同時切換到那個分支上，你可以運行一個帶有 -b 參數的 git checkout 命令：
$ git checkout -b iss53
Switched to a new branch "iss53"它是下面兩條命令的簡寫：
$ git branch iss53
$ git checkout iss53
你繼續在 #53 問題上工作，並且做了一些提交。在此過程中，iss53 分支在不斷的向前推進，因爲你已經檢出到該分支（也就是說，你的 HEAD 指針指向了 iss53 分支）
$ vim index.html
$ git commit -a -m 'added a new footer [issue 53]'
現在你接到那個電話，有個緊急問題等待你來解決。有了 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(+)
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 分支所指向的提交快照中，你可以着手發佈該修復了。
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(+)
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），做一個簡單的三方合併。
和之前將分支指針向前推進所不同的是，Git 將此次三方合併的結果做了一個新的快照並且自動創建一個新的提交指向它。這個被稱作一次合併提交，它的特別之處在於他有不止一個父提交。
需要指出的是，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 <file>..." to mark resolution)
both modified: index.html
no changes added to commit (use "git add" and/or "git commit -a")任何因包含合併衝突而有待解決的文件，都會以未合併狀態標識出來。Git 會在有衝突的文件中加入標準的衝突解決標記，這樣你可以打開這些包含衝突的文件然後手動解決衝突。出現衝突的文件會包含一些特殊區段，看起來像下面這個樣子：
<<<<<<< HEAD:index.html
<div id="footer">contact : [email protected]</div>
=======
<div id="footer">
please contact us at [email protected]
</div>
>>>>>>> iss53:index.html這表示 HEAD 所指示的版本（也就是你的 master 分支所在的位置，因爲你在運行 merge 命令的時候已經檢出到了這個分支）在這個區段的上半部分（======= 的上半部分），而 iss53 分支所指示的版本在 ======= 的下半部分。爲了解決衝突，你必須選擇使用由 ======= 分割的兩部分中的一個，或者你也可以自行合併這些內容。例如，你可以通過把這段內容換成下面的樣子來解決衝突：
<div id="footer">
please contact us at [email protected]
</div>上述的衝突解決方案僅保留了其中一個分支的修改，並且 <<<<<<< , ======= , 和 >>>>>>> 這些行被完全刪除了。在你解決了所有文件裏的衝突之後，對每個文件使用 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
#如果你覺得上述的信息不夠充分，不能完全體現分支合併的過程，你可以修改上述信息，添加一些細節給未來檢視這個合併的讀者一些幫助，告訴他們你是如何解決合併衝突的，以及理由是什麼。
