一般情況下，如果我們在提交代碼的時候發生了沖突，這時候又想保證自己的分支不被污染，同時也不去污染 遠程分支，一般情況下我們都會去新建一個分支去處理沖突，但是這樣會造成分支混亂，會有很多的分支被添加，其中一種解決的方法就是利用 fork 再去復制一份源文件；然后克隆到自己的本地，解決沖突的時候就把在自己 fork 的倉庫里進行修改，但是這樣必須要注意，每次在解決沖突的時候都要從原來的倉庫里拉一下這個代碼，具體的操作
1.克隆 fork 的倉庫代碼；安裝依賴；
2.添加原來的倉庫源，並設置別名，例如 git remote add one git@com(遠程倉庫的地址)
3.拉取原來的倉庫的相應的分支的代碼：git pull one feature/test
4.然后進行相應的兩個分支代碼的合並，沖突的解決；
5.通過 merge request 或者是 git push one:分支名字 再推到遠程倉庫去
其實，解決沖突一般的操作都是直接操作有直接沖突的兩個分支；例如： A merge B；這時候 B 和 A 是有沖突的，那么我們解決的辦法就是，把 A 分支的代碼 pull 下來，然后再去 merge B；這時候再去看看哪里有沖突把沖突解決掉，這樣解決掉之后，下次再提交再 merge 的時候就不會有沖突了，但是這是為什么呢？ 如果我們仔細觀察的時候就會發現，每次我們 merge 的時候，merge 進 A 的代碼都是，我們從上次將 B 分支 merge 進 A 之后，又去進行修改了的代碼；更直觀一點，
第一次，我們修改了 index.js 中的，a = 1； 我們 commit 之后，往 A merge 的時候，我們merge 的部分是 a = 1；這個在 gitlab 的
這個地方就能夠更加直觀的看到；當我們 merge 進去之后；我們再修改了 index.js ，添加了一行 b = 2； 我們接着 commit 之后，往 A merge 的時候，其實這時候我們在 gitlab 上就能看到，我們的 changes 下邊只有 index.js 文件下邊的 b = 2；也就是我們這次 merge 跟上次 merge 只有這一點點的改變；有沒有沖突也只是去判斷這一部分；即使之前的 a = 1； 有沖突，那么上次解決掉了，跟我們這次的 b = 2 ；就沒有一點的關系了；
官方的文檔好像是說，解決完沖突就會有一個標記，下次上傳的時候，即使代碼這里不一樣，但是這個標記有記錄要怎么處理，怎么跳過，這一個說法可以解釋對於不同的地方，之前的 沖突的解決辦法，自我感覺結合着 changes 其實可能會更好的理解；