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

前言

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

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

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

什么是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。那么老王的更新将会消失。所以是不可能这样设计的。

  1. 结果
    那么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

相关推荐
©️2020 CSDN 皮肤主题: Age of Ai 设计师:meimeiellie 返回首页