下面介紹了merge操作中爲什麼會出現parent1和parent2的分叉以及執行git reset --hard commit_id操作爲什麼會導致版本丟失和回滾不乾淨的情況。
1.f_test1和f_test2分支分別修改了不同的文件，都往master上merge代碼
1) 創建f_test1\f_test2分支
git checkout -b f_test1 master
git push
對本地分支f_test1與遠程分支進行關聯:
git branch --set-upstream-to=origin/f_test1 f_test1
創建f_test2分支類似；
2) 在分支f_test1上創建3個文件a\b\c,分別往裏面添加內容；
3) 在分支f_test2上創建3個文件d\e\f,分別往裏面添加內容；
4) f_test1和f_test2分支merge到master分支
5) 查看日誌
從提交日誌裏面可以看到
f_test1的merge操作沒有在日誌裏面打印出來，原因是此時還只是往master上進行單線合併，分支沒有進行分叉。
同時，合併時出現了“Fastforward”的提示。由於當前 master 分支所在的提交對象是要併入的 f_test1分支的直接上游，Git 只需把 master 分支指針直接右移。換句話說，如果順着一個分支走下去可以到達另一個分支的話，那麼 Git 在合併兩者時，只會簡單地把指針右移，因爲這種單線的歷史分支不存在任何需要解決的分歧，所以這種合併過程可以稱爲快進（Fastforward）
f_test2的merge操作在日誌中打印出來了，
這次合併操作的底層實現，並不同於之前 f_test1 的併入方式。因爲這次你的開發歷史是從更早的地方c1開始分叉的。由於當前 master 分支所指向的提交對象並不是 f_test2分支的直接祖先，Git 不得不進行一些額外處理。就此例而言，Git 會用兩個分支的末端（C3 和 C2）以及它們的共同祖先（C1）進行一次簡單的三方合併計算。下圖標出了 Git 用於合併的三個提交對象：
圖1-5-2
這次，Git 沒有簡單地把分支指針右移，而是對三方合併後的結果重新做一個新的快照，並自動創建一個指向它的提交對象（C4）（見上圖）。這個提交對象比較特殊，它有兩個祖先（C2和 C3）。
6) 我們看看執行reset回滾會出現什麼現象
回滾到merge f_test2的時候；
現在我們看看日誌:
從日誌裏面可以看見。Merge f_test1的操作不見了，a\b\c.txt三個文件不見了，我們再回過頭去看一下合併的詳細過程
git merge f_test1執行完之後，日誌的顯示情況:
在本地工作目錄D:\editiontest\git_demo下也增加了a\b\c.txt三個文件
git merge f_test2執行完之後，日誌的顯示情況:
從日誌裏面看，是多了2條紀錄而不是多了一條記錄，
當我們再看圖1-5-2，可以明白，master的頭指針回到了c3，會把c2和c4對象全部都給丟掉，c4是三方合併操作，c2是f_test1的提交內容，但是c3的內容仍然還在，所以對於回滾分叉的提交時，一定要謹慎，說不好就把不該回滾掉的代碼給回滾掉，而想要回滾的內容卻還在，這也是採用reset回滾不乾淨的原因所在；
