3.2 Git 本地分支 - 本地分支的新建與合並
本地分支的新建與合並
讓我們來看一個簡單的分支新建與分支合並的例子,實際工作中你可能會用到類似的工作流。 你將經歷如下步驟:
-
開發某個網站。
-
為實現某個新的用戶需求,創建一個分支。
-
在這個分支上開展工作。
正在此時,你突然接到一個電話說有個很嚴重的問題需要緊急修補。 你將按照如下方式來處理:
-
切換到你的線上分支(production branch)。
-
為這個緊急任務新建一個分支,並在其中修復它。
-
在測試通過之后,切換回線上分支,然后合並這個修補分支,最后將改動推送到線上分支。
-
切換回你最初工作的分支上,繼續工作。
新建分支
首先,我們假設你正在你的項目上工作,並且在 master
分支上已經有了一些提交。

現在,你已經決定要解決你的公司使用的問題追蹤系統中的 #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]'

iss53
分支隨着工作的進展向前推進
現在你接到那個電話,有個緊急問題等待你來解決。 有了 Git 的幫助,你不必把這個緊急問題和 iss53
的修改混在一起, 你也不需要花大力氣來還原關於 53# 問題的修改,然后再添加關於這個緊急問題的修改,最后將這個修改提交到線上分支。 你所要做的僅僅是切換回 master
分支。
但是,在你這么做之前,要留意你的工作目錄和暫存區里那些還沒有被提交的修改, 它可能會和你即將檢出的分支產生沖突從而阻止 Git 切換到該分支。 最好的方法是,在你切換分支之前,保持好一個干凈的狀態。 有一些方法可以繞過這個問題(即,暫存(stashing) 和 修補提交(commit amending)), 我們會在 貯藏與清理 中看到關於這兩個命令的介紹。 現在,我們假設你已經把你的修改全部提交了,這時你可以切換回 master
分支了:
$ git checkout master
Switched to branch 'master'
這個時候,你的工作目錄和你在開始 #53 問題之前一模一樣,現在你可以專心修復緊急問題了。 請牢記:當你切換分支的時候,Git 會重置你的工作目錄,使其看起來像回到了你在那個分支上最后一次提交的樣子。 Git 會自動添加、刪除、修改文件以確保此時你的工作目錄和這個分支最后一次提交時的樣子一模一樣。
接下來,你要修復這個緊急問題。 我們來建立一個 hotfix
分支,在該分支上工作直到問題解決:
$ 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
你可以運行你的測試,確保你的修改是正確的,然后將 hotfix
分支合並回你的 master
分支來部署到線上。 你可以使用 git merge
命令來達到上述目的:
$ git checkout master
$ git merge hotfix
Updating f42c576..3a0874c
Fast-forward
index.html | 2 ++
1 file changed, 2 insertions(+)
在合並的時候,你應該注意到了“快進(fast-forward)”這個詞。 由於你想要合並的分支 hotfix
所指向的提交 C4
是你所在的提交 C2
的直接后繼, 因此 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 將此次三方合並的結果做了一個新的快照並且自動創建一個新的提交指向它。 這個被稱作一次合並提交,它的特別之處在於他有不止一個父提交。

既然你的修改已經合並進來了,就不再需要 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.support@github.com</div>
=======
<div id="footer">
please contact us at support@github.com
</div>
>>>>>>> iss53:index.html
這表示 HEAD
所指示的版本(也就是你的 master
分支所在的位置,因為你在運行 merge 命令的時候已經檢出到了這個分支)在這個區段的上半部分(=======
的上半部分),而 iss53
分支所指示的版本在 =======
的下半部分。 為了解決沖突,你必須選擇使用由 =======
分割的兩部分中的一個,或者你也可以自行合並這些內容。 例如,你可以通過把這段內容換成下面的樣子來解決沖突:
<div id="footer">
please contact us at email.support@github.com
</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
#
如果你覺得上述的信息不夠充分,不能完全體現分支合並的過程,你可以修改上述信息, 添加一些細節給未來檢視這個合並的讀者一些幫助,告訴他們你是如何解決合並沖突的,以及理由是什么。
轉載:https://git-scm.com/book/zh/v2/Git-%E5%88%86%E6%94%AF-%E5%88%86%E6%94%AF%E7%9A%84%E6%96%B0%E5%BB%BA%E4%B8%8E%E5%90%88%E5%B9%B6