使用git向主干分支合並代碼通常采用兩種方式：第一種是merge，第二種是利用BeyondCompare等工具進行比對，將差異合並到主干；
通過merge合並代碼出現沖突時，並不清楚誰的修改和誰的修改發生了沖突，在沒有了解沖突背景的情況下解決沖突可能引入問題；
利用BeyondCompare等比對工具直接將代碼合入會丟失大量的commit信息，影響后續代碼的可追溯性。
個人建議采用git cherry-pick進行代碼合並；首先在自己的開發分支上進行開發調試，驗證通過后進行代碼提交整理，識別功能性提交和調試性提交，將調試性提交與之前的功能性提交進行commit合並，最后將整理后的commit通過git cherry-pick合並到主干分支，具體步驟如下：
1.從主線分支master拉取自己的開發分支self_develop；
2.在自己的開發分支self_develop上進行開發、調試、驗證，直至當前小功能點驗證通過；
3.在自己的開發分支self_develop上執行git log >gitlog.txt, 將commit信息導出到gitlog.txt中，如下所示（請無視中文commit log，這是自己的LaTex文檔庫😀）；
4.使用notepad++等文本編輯器，過濾出以commit起始的commit id信息，從中截取拉取開發分支時的base以及后續開發提交部分，如下所示：
5.利用批量替換將"commit"替換為"git cherry-pick"；拉取分支時的base對應的commit修改為"git reset --hard", 如下所示：
5.將上述文本貼到excel表格中，之前預留一列，通過拖動的方式進行自動編號：
6.在excel中按A列降序排列，進行反轉：
7.將反轉后的信息再拷貝到文本編輯器進行整理，識別哪些是開發功能提交，哪些是為了解決編譯錯誤等進行的調試性提交；調試性提交通過rebase命令合並到之前的開發功能提交中：
8.從自己的開發分支self_develop再拉取一個用於合並的分支self_develop_formerge，執行步驟7中的命令；
首先將self_develop_formerge的代碼回退到拉取開發分支時的base，然后順序執行git cherry-pick添加代碼；
最好逐條執行，便於遇到沖突及時解決，git rebase -i HEAD^^^操作類似vim，有幾個^就是合並幾次提交。
注意：解決沖突時，盡量保留如下沖突示例中的藍色部分代碼，否則后續cherry-pick如果涉及同一部分修改可能持續出現沖突，如果實在需要保留紅色部分代碼，可以等所有cherry-pick都執行完后，再進行最后一次commit修改回來。
+<<<<<<< HEAD
code old //代碼庫中已有代碼
+======= //沖突分界線
code new //從你的develop分支cherry-pick過來的代碼
+>>>>>>> e2316cf... add some function
9.所有命令執行完后，代碼整理結束；再按照步驟3--步驟8同樣的方法將整理后的功能性提交合並到主干分支master；
10.步驟9結束后代碼就合並完了，需要進一步確認一下合並的代碼是否有遺漏，執行一下4條命令即可：
git diff d6129be2 d9414e16 >diff_of_master //d6129be2 d9414e16分別是主干分支合並前的最后一次提交和合並代碼后的最后一次提交
git diff 00322967 2dc90513 >diff_of_develop //00322967 2dc90513分別是調試分支拉取時的base和完成功能調試驗證的最后一次提交
diff diff_of_master diff_of_develop
rm diff_of_master diff_of_develop
如果第三條命令的輸出結果沒有實際代碼的差異（可能有一些commit消息差異，比如同樣的修改，在調試分支和主干分支修改的代碼行數可能不一樣都會體現在diff文件中，這些差異無影響可以忽略），說明代碼合並沒有遺漏，可以放心push到公共代碼庫了。