在提交mr的时候突然遇到了conflict，这时候意识到没有及时pull代码，脑海中想起了隔壁一起入职的同事经常念叨的一句“每天早上来都pull一下代码”。但是已经迟了

我看了一下，主要是同一个文件，master分支上已经被修改过，然后我要mr的代码也在这个文件上进行了修改。因为用的是gitlab，我一开始就在gitlab网页上点击了处理冲突的按钮，点进去的界面是一左一右，左边是我的，右边是master的(theirs)。这个时候，gitlab只给你两个选择，点击左边的“ours”或者是右边的“theirs”，但是显然这两个代码都要被合并在master，所以不能在gitlab上这么操作。

我重新打开idea，点击了右上角的pull，这个时候从master上拉取代码，出现了提示 有冲突。在跳出来的窗口上点击merge，就会进入处理冲突的界面。这个时候界面被分为三个部分，左边是我的，右边是master的。中间这部分比较重要，它是一个实时的预览，展示的是最后的结果。

首先说一下这个界面会出现的几种颜色，绿色表示新加、蓝色表示修改、还有最重要的红色就是冲突的部分。

我一开始理所当然的认为绿色和蓝色我不需要处理，因为这些是没有发生冲突的地方，我认为它会被写入到最终的合并结果里。于是我只处理红色的冲突部分，我是这样处理的：我把左侧我的代码复制，然后粘贴到中间。接着把右侧master中本来就有的代码复制，粘贴到中间。最后点击合并。处理完之后我一看，完了，我之前新加和修改的代码都没了（也就是绿色和蓝色的部分）。

还好我的代码在第一次mr的时候就push到了远程的分支。于是我二话不说把本地的项目删了，重新git clone master的代码到本地，然后在idea里git checkout 到我的本地分支。之后再一次从master上pull代码，于是出现了和刚才一样的事情：存在冲突。这是必然的，在这个时候重新处理一次冲突合并就行了，只需要把蓝色和绿色的代码也一并复制到中间的结果区，最后确定，就可以解决问题。

这件事情告诉我一个道理——每天早上来都pull一下代码。但是严格来时，应该是每次push前都提交一下代码。

另外还要说一下在我处理这种情况的时候，我有上网搜索别人的教程。比如这个我觉得应该是有用的，但是由于我使用git的习惯是命令行+idea按钮，对git命令行不完全熟悉，所以我按照这个教程没有走完

最后再复习一下git的各种颜色：

红褐色：创建之后没有add，没提交，不在版本控制范围之内，这时候文件是红褐色的，需要先add文件；
绿色：add之后是文件绿色的，没有提交（commit）;
蓝色：原本有一个文件，改动过后没有提交（commit）是蓝色的，提交之后，变成正常颜色。