10. 合並分支並解決沖突（conflict）
1) 合並分支
在代碼管理過程中，切換分支或者同步服務器代碼時，常常會出現代碼沖突的情況，這種情況出現的原因一般是由於兩個分支對同一個文件進行修改，
當把這兩個分支進行合並時就有可能會出現沖突（pull遠程服務器上的代碼是一樣的道理）。
以Test倉庫為例，主分支 master 對19264.h文件進行了修改並進行了多次提交，在主分支中對19264.h文件的 lcd_delay_us 函數進行了修改（增加了幾條注釋），
而另一條分支 testconflict 刪除了該文件中的這一函數（也可以是添加了其它的注釋或者改動這一部分的代碼）。
也就是說，19264.h頭文件被多次修改了（在實際的代碼編寫過程中，一般就對應着多人修改同一個文件的情況）
圖 4‑1 提交記錄
右鍵點擊testconflict分支，在下拉菜單中選擇Merge testconflict into master 這一項：
圖 4‑2 下拉菜單
程序將會嘗試將testconflict分支並入master分支。然而這兩條分支是有代碼沖突的，接下來程序就會在最新的提交記錄位置提示我們：
圖 4‑3代碼沖突提示
2) 代碼出現沖突
合並分支出現代碼沖突后，程序右側將會給出發生沖突的文件列表（Conflicted Files）和無沖突的文件列表（Resolved Files）如下圖：
圖 4‑4 文件列表
點擊發生沖突的“19264.h”文件，GitKraken將會進入Diff View視圖：
圖 4‑5文件比較視圖
程序正中央顯示了總共有一個沖突發生：
圖 4‑6發生的沖突
點擊箭頭按鈕可以快速定位到發生沖突的地方。
左側的 
部分顯示的是 master 分支中提交記錄的文件內容，在20~22行后面添加了一些注釋；右側的 
部分顯示的 testconflict 分支中提交記錄的文件內容，
可以看到 15行的 #define 定義下面的函數是 lcd_delay_ms 函數而不是 lcd_delay_us 函數，也就是之前提到的刪除了 lcd_delay_us 函數。
下方的Output顯示的是最終將會保留的文件內容。
3) 解決沖突
當代碼出現沖突后，需要手動解決沖突。在代碼沖突的位置，
兩部分各有一個復選框。若點擊 
側的復選框，將會保留master分支中對該段代碼的修改：
圖 4‑7 保留master分支對代碼的修改
可以看到Output中將會保留這段函數代碼及添加的注釋。點擊右上方的 
按鈕將會將Output框中顯示的內容保存到文件中，即沖突被解決。
如果確定了需要保留 
的所有代碼，將 
左邊的復選框選中，將會保留master分支的所有更改：
圖 4‑8 保留A的所有更改
如果只需要其中的一部分代碼，可以點擊 
記號，取消這個標記，就像下圖一樣：
圖 4‑9 保留部分更改
那么Output框中現實的內容就會變成這樣的：
圖 4‑10 輸出結果
可以同時保留 
中的部分修改，又保留 
中的部分修改。最后解決沖突，保存文件。代碼合並的工作就完成了。
完成以上工作后，需要對代碼合並進行一次新的提交：
圖 4‑11 合並分支並提交
填寫合適的Commit Message，並點擊 Commit and Merge 按鈕。在提交記錄區將會出現一個新的提交記錄。
解決了代碼沖突后，就可以繼續進行代碼編寫了。從服務器上拉取（Pull）代碼，有時也會提示代碼沖突，原理與此類似，只是發生沖突的分支不同而已（一個是master分支，一個是 origin/master分支）。