問題描述：
在gitlab上面做合並操作，出現沖突，解決沖突后提交，確認合並，發現兩個分支互相合並了，平白無故多了很多麻煩，巨坑。
已經被它坑了不少次了，如果使用 Gitlab 提供在在線沖突解決工具的話，本來是將 A 往 B 合並的，結果變成了 B 往 A 合並，導致分支管理混亂。這個設計合理嗎？
git正常的合並分支：
切換到目標分支
執行合並命令，git merge 源分支
沒有沖突合並結束，出現沖突，在目標分支上面解決沖突，執行commit命令，合並結束
然而，gitlab上面做合並分支的操作，出現沖突時，gitlab是在源分支上面提交我們解決沖突的代碼，最后點合並的時候再把源分支合並到目標分支，這就導致合並結束后，源分支與目標分支出現互相合並的效果，產生很多沒必要的問題。
后來才找到原因：
解決方法：
方法1：設A分支要合並到B分支，且出現了沖突，可以先從A分支拉一個臨時分支a，用a分支合並到B分支
方法2：設A分支要合並到B分支，且出現了沖突，合並完成后，對A分支做回滾
git回滾版本：
git reset --mixed 目標版本號，回退一個版本,且會將暫存區的內容和本地已提交的內容全部恢復到未暫存的狀態,不影響原來本地文件(未提交的也不受影響)
git reset --soft 目標版本號，回退一個版本,不清空暫存區,將已提交的內容恢復到暫存區,不影響原來本地的文件(未提交的也不受影響)
git reset --hard 目標版本號，回退一個版本,清空暫存區,將已提交的內容的版本恢復到本地,本地的文件也將被恢復的版本替換
回滾后再強推到遠程git服務器：git push -f origin test 強制推送到遠程分支，-f 強制，origin 遠程倉庫名，test 遠程分支名
git revert 目標版本號
這個命令在本地反向做一個版本抵消目標版本，然后正常commit提交，push到遠程分支
原文：https://blog.csdn.net/superyueguang/article/details/114309492