問題描述
我們在主干dev和branch1分支上進行並行開發。當要把branch1功能的代碼合並到dev上時，發現dev上開發的部分功能代碼找不到了。
那么，是在branch1上，作了刪除提交導致的嗎？然而，查提交日志，並沒有發現刪代碼的提交記錄。
難道一個分支有一個功能，另一個分支沒這個功能，git合並時就有可能把這塊功能代碼丟掉？跟功能添加時間順序有關系？
為了解決這個問題和相關的疑問，我們需要先了解下git合並的過程。
git-merge過程
稍微了解點git基礎的應該都知道，合並是用的git merge命令。它只有兩種，一種是快速合並(fast-forward)，還有一種是三方合並(thirdparty merge)。
如上圖所示，當兩個分支有直系關系時，使用快速合並，git不產生新的commit結點，只是把head進行更新，如dev指向C4。
三方合並稍顯復雜點，它會產生一個新的commit結點，並把head指向它。它會先去找這兩個要合並分支的最近公有結點，如圖中，C3 和 C5的最近公有父結點為C1。然后，git對 C1、C3和C5三個結點進行三方合並產生新結點C6。這里的三方合並，具體來說，就是把 C5相較於C1的 diff差異應用到 C3上，最后產生C6 這個commit結點。
現在回答上面的疑問，三方合並其實只看三個點的內容，和中間結點無任何關系，更別提跟時間有關系了。在一個分支上刪除代碼，如果合並時沒有沖突的話，合並后是會直接刪除的。
所以，我們找到了問題的初步方向了。dev上的代碼合並后沒了，一定是branch1分支有問題！！！
注：知道了git-merge的流程后，我們還可以知道，只要我們把這次合並代碼丟失問題解決了，后續從branch1分支拉出去的分支代碼再合並到dev時，都不用再解決這個代碼丟失問題了。因為，合並后的提交結點和branch1分支拉出去分支的后續提交結點的父結點，已經變成branch1的當前結點了。如，
C6的后續提交和C5的后續提交結點，公有結點都變成C5了。
問題起因及檢測
為了描述問題方便，我把場景簡化，搞了個demo，大家可以去下面地址clone：
# git clone https://git.coding.net/myswift/git-merge.git
提交記錄用sourcetree看，是這樣的（你可能已經發現問題了）：
dev合並branch1時，dev上，dev func 1部分的提交丟失。
首先，讓我們找最近公共結點吧。如果兩個分支並行太久的話，可能不好直接找出來。我們可以使用git merge-base:
# git merge-base 98d19a4 0acedcb
9447776f5ee8c53536c947a1e13bfdead13f002b
我們發現最近的公共結點是9447776。然而，這個公共結點，並不是我們設想的。我們設想的最近公共結點應該是兩個分支剛開始並行的那個結點（如圖中c3275e2)。進一步發現，9447776的下一個結點有個Merge，而且是把dev合並到branch1！！！
這就是問題的根源了，dev主干開發的一般是下個版本的功能，一般是把分支的代碼合到主干上，把主干的代碼逆向合並到分支上肯定是有問題的！！！
回到開頭的問題，我們看Merge結點變更記錄，並沒有發現有刪除代碼的地方啊？原因是，你看到的合並結點的修改記錄，是針對一邊的。回到介紹三方合並的那個圖，把branch1合並到dev產生結點C6，那么C6的提交記錄中顯示的修改，是C6針對C3結點的。在我們的示例中，合並結點74a8d10的提交變更，顯示的是74a8d10對branch1中c26c5e3的變更，而branch1中本來就沒有dev中的代碼，所以合並后變更根本不會顯示刪除。
如果，你去比較合並結點和另一邊的變更，你就可以發現問題：
# git diff 9447776 74a8d10
diff --git a/test.c b/test.c
index 150de8d..d19a020 100644
--- a/test.c
+++ b/test.c
@@ -7,8 +7,8 @@ void base_func() {
printf("this is a crash %d\n", *p);
}
-void dev_func_1() {
- printf("dev func 1\n");
+void branch_func_1(){
+ printf("branch func1\n");
}
你可以明顯看到，在合並時，把dev中的dev_func_1函數刪除掉了。
總結問題的原因是，在正式合並前，進行了逆向的合並，並在合並中悄悄把主干代碼刪除掉了。一般如果查看提交記錄中，沒有看到刪除記錄，那么很有可能是之前的Merge中把代碼刪除了。可以使用 merge-base和git diff 工具來進行定位，也可以用來檢測是否有問題。
注：很多人可能認為只要管好自己的分支就行了，然后把別的分支合過來，並在合並時或合並后隨意刪除另一分支的代碼。這樣當以后再和該分支合並時，就會有問題。好的做法，應該是只把另一個分支上你需要的提交用cherry-pick移過來，而不是直接合並別人的分支，再刪除你不需要的代碼。如，只把dev上的
fec5b84優化cherry-pick復制到branch1上即可。
解決思路
既然我們發現了問題的原因，並知道怎么去規避、檢測。那么，如果已經發生了問題，怎么去解決呢？這個可能是大家更關心的。
其實我們最終的目標是，把branch1和dev進行合並，產生一個合並節點，並且這個合並結點的代碼是正確的。
注：有些人可能不太明白為什么一定要產生一個git合並記錄節點。通過各種手段，只要保證dev上代碼正確不就行了？結論是不行，因為如果沒有git合並記錄的話，從branch1拉出來的所有分支再想合並到dev時，還是要解決下這個代碼丟失的問題（沒想明白，可以再看下前面git-merge過程部分)，而且如果把branch1分支懸着不合並，也影響分支查看。
確保合並后代碼正確
奔着這個目標，我們首先來確保代碼的正確。
1. dev重置到合並前
既然最后合並branch1到dev會導致dev丟代碼，我們首先把dev重置到合並前。
# git checkout dev
# git reset --hard HEAD~1
2. 創建tmp分支，繞過錯誤的合並74a8d10
我們知道branch1是有問題的，因為進行了合並dev的操作。所以，基於branch1創建一個臨時分支tmp。
# git checkout branch1
# git checkout -b tmp
把tmp的提交記錄重塑，使tmp分支回到branch1上的，合並dev到branch1那個錯誤的合並之前的結點，示例中 74a8d10之前的那個c26c5e3結點，並提交一個新記錄，這樣tmp內容與branch1一樣，而完全跟那個74a8d10結點沒關系了。
# git checkout tmp
# git reset c26c5e3
# git add .
# git commit -m "內容與branch1一致"
注：reset和reset --hard的區別，可以參考文末資料1。
3. 合並tmp到dev
# git checkout dev
# git merge tmp
這里dev和tmp合並時，它們的最近公共結點就不是之前錯誤的9447776了，而是我們設想的、dev和branch1最初分開的，c3275e2結點。
解決沖突，並add進暫存區后，我們代碼就是正確的了（先不急着提交）。
產生合並commit對象
上面代碼正確了，如果我們直接commit的話，這個合並結點，就變成dev和tmp的合並了，而我們要的是dev和branch1的合並。所以，我們要產生一個dev和branch1合並的結點，並且內容是當前dev和tmp合並后的代碼。顯然，git merge不能滿足我們的需求，我們需要更底層的git命令，就是git merge過程中，調用的底層命令。
需要按序要用到 write-tree -> commit-tree -> update-ref，這三條底層命令。這部分命令，可以查看參考資料2。
1. write-tree產生tree對象
# git add .
# git write-tree
853c36012082314f9463f3819d0a24da49dc5bb1
我們產生了SHA-1值為 853c360的tree對象。
2. commit-tree產生commit對象
# git commit-tree 853c360 -p 98d19a4 -p 0acedcb -m "Merge branch 'branch1' into dev"
675baf3973508ee03306cc5a36fe489d694e107f
我們把tree對象 853c360進行了提交，並設置它的兩個父結點為dev和branch1，產生了commit對象675baf3。我們可以看下這個結點的情況：
# git cat-file 675baf3 -p
tree 853c36012082314f9463f3819d0a24da49dc5bb1
parent 98d19a4a5913f18a2c0e9821e114df9995b23d82
parent 0acedcb89e4d25a0256fcbe7fba0bbc13de9d92e
author Vincent <xxx> 1498497182 +0800
committer Vincent <xxx> 1498497182 +0800
Merge branch 'branch1' into dev
3. 更新head
使用如下命令，更新dev指向這個新的commit對象, 675baf3：
# git update-ref refs/heads/dev 675baf3
最終合並結果如下：
可以驗證，branch1合並到dev了，而且內容是正確的（即不會少dev fun 1部分的代碼）。
這個解決問題的示例代碼，也上傳到coding了，兩份示例代碼，之前的結點都是一致的。
# git clone https://git.coding.net/myswift/git-merge2.git
注：知道了git merge這些底層命令，你可以更加靈活地解決git問題，你可以結點隨意合並，head隨便指，是不是很開心，哈哈。
更粗暴的方法
如果你覺得底層命令不好理解。你可以：
-
先整個目錄拷備下工程（包含.git目錄)，比如拷貝到bak目錄
-
在工程中直接合並branch1到dev上，不解決沖突，不提交
-
在bak目錄，按照上面確保代碼正確的方法，在bak目錄合並出正確的代碼。
-
把bak目錄中，除了.git目錄外的東東，全部拷貝覆蓋到原來工程目錄中
-
在原來工程目錄中，提交
這樣比較好理解，缺點是工程如果大的話，拷來拷去花費時間比較長，而且不夠優雅。
其他解決思路
上面描述的思路，我認為是最行之有效的。也試了其他思路，比如：
-
查看git merge的參數，發現並沒有可以自由設置base節點的方法，只有設置發現base節點的策略，而且這些策略發現的base節點都是那個錯誤的合並。
-
undo merge。參考資料3。然而，感覺revert merge的能力有限，加-m1參數、和-m2參數，均無法滿足要求。
-
rebase branch1。錯誤發生在branch1，那么重建branch1呢？把所有branch1上合並后的提交都重新提交呢？結果發現branch1上有太多合並沖突，rebase時，要把這個合並的沖突重新解決，很麻煩。
這些思路，大家也可以繼續研究下，感覺不能解決問題，也可能是我了解得有問題。當然，你有其他思路，也希望你交流下。
迷思
本文中，是因為錯誤地把dev合並到branch1上，導致了后面合並的問題。但是，我們真實遇到的場景，雖然看起來是一樣的，也可以用文中的方法解決，但是也有細微不同，而且不知道如何出現這個問題。
真實的場景下，也會出現一個dev合並到branch1的Merge提交，但是顯示的信息是 "Revert xxx"，據提交人員講，這個確實是做的Revert操作，不知如何變成Merge結點了。用的sourcetree，提交人員也沒法說清怎么必現這個問題。
如果，你知道怎么操作能出現這個問題，希望你告訴我。。。
總結
文中描述了一種可能導致git合並代碼丟失的錯誤操作，並講解了如何規避、檢測、解決這種錯誤。並粗略介紹了，git merge流程，git merge底層過程。
說簡單點，問題是因為悄悄在合並中把代碼刪除了。解決思路是，悄悄在后面的合並中把代碼加回來。