[SourceTree - Git] 如何解决冲突& (以我的版本解决冲突&以他人版本解决冲突)_sourcetree merge 冲突

前言

在开发过程中， 经常会遇到冲突。 下面我们分几点来讲述：

• 什么是冲突？为什么会产生冲突？
• 冲突的解决条件。
• “以我的版本解决冲突 & 以他人版本解决冲突” 两者的区别

---

什么是冲突？冲突的产生原因？

什么是git push? 也就是代码提交操作？

我们都知道git是基于一棵树进行维护的. 想要将代码更新到远端结点. 必须满足如下几个条件:

• 本地树版本与远端树版本一致
• 更新基于远端的头部结点更新

光看文字可能有点抽象，我们用图像来描述这个步骤:

已知远端的版本为A-->B-->C. 本地的版本也为A-->B-->C. 但是本地有所更新，于是在C结点之上创建了结点D. 现在的操作步骤主要是2个步骤：

1. 创建结点D，并推送到本地树内；
2. 将D结点的操作推送到远端树。即本地树与远端树进行同步。

当更新成功后，远端的树结点应当为如下结构。

什么时候会出现冲突？冲突如何产生？

如果只有一个人进行开发。那么Git树必然是线性的。可就不会出现冲突的情况。
但是我们开发通常是多人开发。多人开发提交也就是冲突产生的起因。

我们先来想象有2个人进行开发的场景，一个叫张三，一个叫老王。

1. 首先远端结点。老王和张三都拉取了最新的代码。
   

2. 随后老王有了修改，并且同步到了远端。
   

3. 但是，此时到张三并不知道这样到情况出现。他自己更新了版本F，也想提交到远端。
   

4. 此时张三会更新失败！！！
   为什么？因为我们之前说的push的前置条件为1 本地树与远端树保持一致；2 并且在头结点进行更新. 我们来看下张三提交时候的树的情况:

   • 远端树 A--B--C--D--E
   • 老王树 A--B--C--D--E
   • 张三树 A--B--C--D--F

张三想把D--F这部分的内容同步到远端。如果更新成功那么远端树会变成A--B--C--D--F。那么老王的更新将会消失。所以是不可能这样设计的。

5. 结果
   那么git树真实情况是如何设计的呢？
   其实这里也分2种情况: 操作同一文件，产生冲突 / 非操作同一文件，创建Merge结点

5.1. 我们先来说非操作同一结点的情况：

这里张三树主要做了2件事情：

• 同步D--E这部分的结点。即将本地树同步与远端树一致。
• 将F结点作为E结点之后。然后Push到远端。

注意： 这种自动提交到问题自然会出现一个问题。那么当操作同一文件的时候必然会产生冲突。也就是自动Merge操作失败的情况。这里我们需要回退本地结点，进行手动Merge。这里其实也分2种情况操作同一文件的同一行 / 操作同一文件的不同行。前者可以使用工具Merge ，后者需要手动Merge。

---

实战1 - 自动Merge (操作不同文件)

略。

---

实战2 - 手动Merge(操作同一文件的不同行 / 操作同一文件的同一行)

• Version A
  
• 网页更新Version B - 不同行操作 - 利用网页更新-模拟是有另外一个人更新的情况
  
  
• 本地更新Version C
  

可以看到我本地A--C 而远端为A--B. 直接提交必然会导致异常.

hint: Updates were rejected because the tip of your current branch is behind 这个说的就是我们的本地版本滞后了。

• 我们现在先使用git pull拉取一下。看看本地能否自动更新。
  
• 出现冲突
  

出现冲突，我们现在有2个选项：

• 以我的版本解决冲突；
• 以他人版本解决冲突；
• 手动修改文件

---

Quick Merge(以我的版本解决冲突 & 以他人版本解决冲突)

• 我们先试试，以我的版本解决冲突
  
  生成一个空的Merge结点。
  
  可以看到，本地关于version.txt文件的修改消失了。

可以看到这时的我的版本，指的就是版本C。此时的Version.txt恰好是版本C.

---

• 再试试，以他人版本解决冲突
  

可以看到。以他人版本解决冲突就是版本B. 即用远端版本覆盖本地版本更新.

---

• 手动合并
  
  上方表示Version C也就是本地的版本。下方表示version B, 也就是远端版本.
  我们手动合并文件到我们希望到情况。

---

结论

什么时候会出现冲突？
答: 当项目有两个或两个以上的人操作。且更新同一个文件的时候会出现冲突。

冲突如何解决？
答: 冲突经常有3种解决方法:

1. 以我的版本解决冲突。 即对于冲突的文件以本地缓存覆盖远端. 会导致远端修改丢失；
2. 以他人版本解决冲突。即对于冲突的文件以远端缓存覆盖本地. 会导致本地修改丢失；
3. 手动解决冲突。这也是我们经常推荐的解决冲突的方式。head >>>/ ===/>>>上方表示本地修改，下方表示远端修改。

其他:

1. 冲突的产生一定是本地结点有滞后导致的。
   但是本地有时也有结点超前于远方。这就是难办的原因。
   为此, Git会自动创建一个合并结点来合并本地和远方。你本地的提交其实这时就相当于一个临时分支。

2. 以他人版本解决/以我的版本解决
   由于我的版本滞后于远方。
   以我的版本解决。即用我的版本覆盖服务器版本
   以他人版本解决。即用服务器版本覆盖我本地版本。
   由此，可以看出都不太合适。都会出现某些覆盖导致异常的情况。所以，我们大多选择手动进行合并冲突。

---

Reference