前情提要：为什么我的代码突然打架了？
处在重要场景模拟中, 去想象这样一种场景, 即你跟同事, 是同时针对feature/login这个分支, 对UserService.java当中的第88行代码做了修改。当你满怀自信地去执行git pull时, 终端呢, 突然就跳出了刺眼的红色提示。
CONFLICT (内容): 在UserService.java中存在合并冲突。
发出灵魂拷问, 处在这样时候, 你该采取怎样的办法? 是直接去删除同事所编写的代码吗? 又或者是将自己所做的改动全部放弃掉? 并非如此！要让经验丰富之人为你指引, 只需三分钟, 就能掌握正确应对Git冲突的解决方式！
一、必看分析中提到的, Git冲突产生的三大元凶里的, 同文件修改陷阱, 是1.1 的内容。
在情况为, 多个开发者, 于同一时间, 对同一个文件的同一区域进行修改时, 举例而言也就是说, 都在登录模块那里添加新功能的状况下, Git没有办法凭借自身自动去判别应该保留哪一个版本。
1.2 分支合并大乱斗
常见于长期不合并的feature分支，比如：
```bash
危险操作示范！
git checkout main
运用git进行merge操作, 针对feature/payment, 此处极有可能引发连环冲突。
```
1.3 文件删除争议
A同学把old_util.py给删除掉了, 然而B同学却于这个文件之中添加了全新的方法, 此时此刻Git不禁会陷入困惑这个情形的迷茫状态: 究竟该去听从谁的指令才好抉择呢?
二、冲突解决四步神操作（实战图解）步骤1：开启上帝视角
运行git status查看冲突文件列表，你会看到：
Unmerged paths:
双方面都被修改了: 源文件主目录下的Java文件夹里的com示例文件夹中的用户服务Java文件。
步骤2：打开战场文件
用IDE或编辑器打开冲突文件，会看到明显的冲突标记：
```java
