讲两种情况下的冲突，可应用于大多数冲突
特性分支合到测试分支上
工作中每写一个功能都会新建属于自己的特性分支。当功能做完时，会进行测试。但是测试环境是一个大的环境，所有人写的代码都会合到这个分支里进行测试，这里难免会与同事的代码冲突。
特性分支 A --> 复杂分支stage
$ git fetch //拉取最新代码
$ git checkout stage //切换到复杂分支里面
$ git reset --hard origin/stage //重置当前代码和远程stage分支代码一致 确保代码是和线上一致的
$ git merge A //把特性分支A的代码合到stage上
冲突 (此时分支名会变成stage/MERGE1/19) 表示有冲突了
解冲突 打开编辑器 查看合并更改 修改结束后 记得全局搜索 <<<< 确保所有的冲突解决完
解完冲突：
$ git add .
$ git commit
$ git push origin stage //此时冲突解决完 stage有了自己特性分支A的代码
**自动合并成功 stage已经更新
特性分支合到master分支/临近上线最后版本的分支
以防万一，会有一个临近上线的版本 也就是测试结束后 修改过后的代码，会再合到这个分支，再次查看 一般此分支代码都是严格修改后的 不可被污染的
特性分支B --> 简单分支uat
$ git checkout B
$ git fetch
$ git merge origin/uat //这时候特性分支相当于复杂分支 包含了uat内没有的代码 所以要把uat拉到自己的特性分支中去解冲突 并且 这个分支 也不允许push 一般是没有权限的 容易出事
解完冲突：
$ git add .
$ git commit
$ git push origin ly-xxx //推到自己分支
**需要再次请求合并 就不会有冲突了 uat还没有代码
