一、前言

1、什么是冲突

• 冲突是指当你在提交或者更新代码时被合并的文件与当前文件不一致。读起来有点绕，结合下面的案例理解。
• 从上面对冲突的定义来看，冲突时发生在同一个文件上的。

二、实战分析

1、生产上冲突的场景

1.2、常见冲突的生产场景如下：

• 更新代码
• 提交代码
• 多个分支代码合并到一个分支时
• 多个分支向同一个远端分支推送代码时

1.3、git的合并中产生冲突的具体情况：

• 两个开发者（分支中）修改了同一个文件（不管什么地方）
• 两个开发者（分支中）修改了同一个文件的名称

注意： 两个分支中分别修改了不同文件中的部分，不会产生冲突，可以直接将两部分合并。

总结： 上面各种情况的本质都是，当前文件与合并文件不一致，因此不论哪种情况其解决冲突的方法是一样的。

1.4、强制回滚到指定的提交记录版本

• 场景：当我们有时候在自己的本地上失误修改了东西，或则出现了很多冲突合并失败的代码。那么这个时候保持没有意外的情况下，可以直接回滚到最新提交记录的那个版本，这样就能一下子复原。
  

三、idea中解决冲突

1、模拟场景分析

假设有另个开发人员开发同一个项目，并且编写同一个文件,工作流程如下：

• 01号程序员先上传文件 conflict.txt，并继续在 conflict.txt上写代码
• 02号程序员更新项目代码，并在 conflict.txt 上写代码，写完后，在提交到远程服务端
  
• 当01号程序员把写完后，准备提交代码了，这时的正规操作手法，先更新在提交，但是在更新的时候必然会冲突，因为这时候更新的代码 conflict.txt 与本地仓库代码 conflict.txt 不一致
  
• 提交前，我要更新，冲突了：
• 解决上图中的冲突方案如下：
  • Accept Yours：代表以自己的为准
  • Accept Theris：代表以更新下来的文件为准
  • Merge：代表手动合并
• 一般解决冲突我们都是选择 Merge
  
• 将需要的内容点击：">>"既可以合并内容到 result 中，不需要的内容点击“x”即可，合并完成后点击 apply 即可。
• 值得注意的是，最后将所有的“x >>”符号都要处理完，不需要的点击“x”,需要的点击“>>”
• 最后，不论是什么场景下产生的冲突解决方法是一样的。

四、关于冲突的个人心得

• 多人协作开发的时候如果出现了你没有改过的文件跟你冲突了，一定要去找到当事者，说清楚是如何冲突的。
• 然后协商解决，千万不要擅自拉别的分支去试图解决冲突，或找文件覆盖，更或者以自己的文件为准。
• 同时记住解决了之后要add 和 commit 最后push，为保证万无一失，最后在冲突都解决之后重启项目。
• 保证至少不会有立即奔溃的现象发生然后才去提交push
• 提交的时候一定要保持清醒先搞清楚自己要提交的文件之间的关系然后再提交，这样才不会有文件缺失的问题造成奔溃
• 如果任务比较多又开了多个分支分别进行开发，再次强调一定要清楚自己在各个分支上做了什么，自己要提交的是什么，最好是能做个详细的笔记，没有把握宁愿不要去提交到生产服务器
• 提交代码的时候不要走神，因为这是一个神圣的时刻。