Git Merge(合併分支)

在學習使用Git 作為版控時，常回遇到不同分支版本分歧的問題，而git 的merge和git rebase 提供了不同分支合併時的方法，這兩個選項都有其優缺點，在下文中，我們先討論如何使用git merge來處理分支合併的問題。

讓我們來看一個你在實際工作中，有可能會用到的merge工作流程的簡單範例， 你做了以下動作：

1. 你與其他member共同開發一個網站。
2. 你建立一個分支(Feature)以實現一個新的user story。
3. 其他的member原本的分支(master)分支上進行開發。

下列的指令模擬了以上的情境

1.建立一個共同開發的網站

mkdir mergeTutorial1
cd mergeTutorial1
git init
echo 1 > file1.txt
echo 1 > file2.txt
git add file1.txt
git commit -m "C1"
git add file2.txt
git commit -m "C2"

2.建立一個分支(Feature)以實現一個新的 user story

git checkout -b feature
echo 1 > file3.txt
git add .
git commit -m "C3"
echo 1 > file4.txt
git add .
git commit -m "C4"
echo 1 > file5.txt
git add .
git commit -m "C5"

3.你的TeamMemeber在master分支開發其他的功能

git checkout master
echo 1 > file6.txt
git add file6.txt
git commit -m "C6"
echo 1 > file7.txt
git add file7.txt
git commit -m "C7"


透過GitKraken看到實際的分支情況(青藍色是master、深藍色標記是feature)

如果我想要 feature分支來合併 master分支的話，會先切回 feature分支：

git checkout feature
git merge master


或是這一行指令

git merge feature master


以上的方法都會建立一個新的"merge commit"到feature 的branch，並且繫結歷史紀錄至feature branch，如下圖

可以看到feature branch多了一個'Merge branchmaster into feature' 的commit ，這是git幫你自動產生的 commit message

merge是一個比較沒有破壞性的合併，因為現有的master branch不會有任何改變，只有feature多了一個commit message，至於下一次介紹的rebase，它就會有改變原有git log潛在的風險

另外一方面，上圖代表了feature branch會顯示從master branch進來的commit，如果master branch常常commit，這很容易汙染feature branch的commit log，雖然這可以透過 git log 來了解這各個commit 的來源，但假如不透過git GUI工具的話，仍很難直接理解feature的commit history.

A 合併 B或跟 B 合併 A 有什麼不同？

這個問題在我一開始學 Git 的時候也曾經困擾過我好一陣子，到底誰合併誰有那麼重要嗎？就實際演練吧!在一次地，讓我們來看一個在實際開發中，有可能會用到的merge工作流程的簡單範例， 做了以下動作：

1. 你與其他member共同開發一個網站，但有些member則是在修以前的bug
2. 你建立一個分支(dev)以開發一個新的user story
3. 其他的member建立了一個新的分支(ticjer)分支修改bug

1.建立一個共同開發的網站
mkdir mergeTutorial2
cd mergeTutorial2
git init
echo 1 > file1.txt
echo 1 > file2.txt
git add file1.txt
git commit -m "C1"
git add file2.txt
git commit -m "C2"


2.建立一個分支(dev)以實現一個新的 user story
git checkout -b  ticket
git checkout -b dev
echo 1 > file3.txt
git add .
git commit -m "C3"
echo 1 > file4.txt
git add .
git commit -m "C4"
echo 1 > file5.txt
git add .
git commit -m "C5"


3.你的Team Member在ticket branch修正之前修改的bug

git checkout ticket
echo 345 > file1.txt
git add file1.txt
git commit -m "C6"
echo 234 > file2.txt
git add file2.txt
git commit -m "C8"
echo 1 > file7.txt
git add file7.txt
git commit -m "C9"


透過GitKraken看到實際的分支情況(青藍色是master[C1、C2]與ticket[C6、C8、C9]、深藍色標記是dev[C3、C4、C5])

這時我想將ticket的分支合併至dev

git checkout dev  

git merge ticket  


為了要進行這次的合併，git 做出了這個額外的 Commit 物件，這個 Commit 會分別指向 deb跟 ticket這兩個分支，HEAD 隨著 dev分支往前，而 ticket分支停留在原地：

如果是想將dev的分支合併至ticket

git checkout ticket
git merge dev

所以，到底要誰合併誰，決定在於哪一個分支先要取得哪一方commit 的部分，以上述的情境來說，當其他的member於bug修完ticket 後，要於dev測試新功能與修完的bug是否有影響到時，理當將ticket merge進dev。