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

最新推荐文章于 2024-09-20 11:23:11 发布

在风中的意志

最新推荐文章于 2024-09-20 11:23:11 发布

阅读量7k

点赞数 9

分类专栏： 19. 版本控制 -------19.1. git 文章标签： git source 版本冲突

本文链接：https://blog.csdn.net/u010416101/article/details/113486315

版权

19. 版本控制同时被 2 个专栏收录

10 篇文章 0 订阅

订阅专栏

-------19.1. git

10 篇文章 0 订阅

订阅专栏

前言

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

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

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

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

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

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

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

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

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

当更新成功后，远端的树结点应当为如下结构。
在这里插入图片描述

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

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

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

首先远端结点。老王和张三都拉取了最新的代码。
随后老王有了修改，并且同步到了远端。
但是，此时到张三并不知道这样到情况出现。他自己更新了版本F，也想提交到远端。
此时张三会更新失败！！！
为什么？因为我们之前说的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。那么老王的更新将会消失。所以是不可能这样设计的。

结果
那么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种解决方法:

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

其他:

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

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