一般情况下，如果我们在提交代码的时候发生了冲突，这时候又想保证自己的分支不被污染，同时也不去污染 远程分支，一般情况下我们都会去新建一个分支去处理冲突，但是这样会造成分支混乱，会有很多的分支被添加，其中一种解决的方法就是利用 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 其实可能会更好的理解；