切记不要在gitLab上解决daily/dev的冲突，以及如何快速 revert Merge

@[TOC]切记不要在gitLab上解决daily/dev的冲突，以及git如何回退merge记录

一、 自己建的分支，只有自己修改，然后提交，提示需要先pull拉取一下，为啥？

原因分析：从gitLab新建一个分支（远程），想从vscode切换到该分支时，使用了第一种方案，vsCode切换到master，但是没有拉取最新的代码（本地master分支 版本落后），然后新建一个重名的分支，导致这两个重名分支后面自动关联时，版本不一致

从gitLab新建一个分支，想从vscode切换到该分支时，发现没有搜到远程的该分支origin/，解决方案目前有两种：
1、vsCode切换到master（本地），拉取最新的代码，然后新建一个重名的本地分支；相当于新建了两个重名分支，后面git会自动关联
2、使用fetch抓取所有分支，就可以搜到该远程分支，就可以从远程的该分支来创建本地分支 ——推荐用法

二、切记不要在gitLab上解决daily/dev的冲突，不然会将daily/dev Merge到我们的分支，后面合生产时就会有「将别人代码合到生产」的问题；解决冲突有两个方案，一个是以daily为基准去解决冲突，一个是以我们自己的分支为基准去解决冲突;

Merge到master的冲突，可以直接在gitLab上解决；

三、解决Merge冲突有两个方案：

1、以daily为基准去解决冲突；使用最新的daily拉取副本分支，然后将我们的分支代码Merge到daily的副本，手动解决冲突，提交后，去gitLab上提MR；—— 适合解决复杂冲突，需要保存两者，甚至是保存两者之后需要修改的冲突；
2、以我们自己的分支为基准去解决冲突，使用我们自己的分支代码拉取副本分支，直接去gitLab上提交MR，有冲突直接在gitLab上解决即可；—— 更简单，适合解决简单明了的冲突；
均需要delete source Branch

四、daily/dev打包时，会自动将master的代码merge到daily/dev，当有冲突时，需要重新以origin/daily为基准拉取一个分支，Merge origin/master into daily，手动解决冲突后，提交 merge到 origin/daily;

五、直接在gitLab上解决冲突，会将daily上的代码Merge到自己的分支上，将来合master，会将daily上无需合到master的代码合到master; 万一这么操作了，该怎么办呢？

revert方案：
1、在工作分支，执行revert merge操作
git revert -m 1 048d0aa2d2b2985432f3923ab1f7bcac5c1e5fce
2、将工作分支Merge到master，即可
终极方案：
1、在工作分支上找到错误的Merge记录（Merge daily into 当前分支），然后在该记录之前重新拉取一个中转分支；
2、若工作分支的这个错误的Merge记录的上面有其他的提交记录，需要cherry pick到新的分支；
3、然后通过比对工具（文件夹比较与合并，推荐App Beyong Compare），全量比对工作分支和中转分支，在差异文件中，将中转分支的代码 全量复制到工作分支上；—— 此时获取到相当于revert Merge 的变更；
4、然后在工作分支上将全部的变更提交（revert Merge）；
5、最后将工作分支Merge到master；

解决代码冲突要注意的问题：—— 红线

1. 不要简单的全部采用传入的更改，而是要一个一个的去检查，看看到底是采用传入的更改，还是需要我们保留二者的变更（可能需要适当的变更），尤其是解决master的冲突；
2. 解决冲突时，遇到他人代码，不确定如何解决时，要找对应的开发同学；
3. 合并”解决代码冲突“代码的时候，开发同学最好能够检查一下；

其他相关沉淀

1. git remote -v 查看当前的远程仓库地址 git remote set-url origin 新地址 ， 重设远程仓库地址