git冲突是如何引起的，如何解决？

Posted 2021-07-31 傲骄鹿先生

写在前面：

• 我热爱技术，热爱分享，热爱生活， 我始终相信：技术是开源的，知识是共享的！
• 你的支持是我创作的最大动力，谢谢支持!
• 个人除了分享博客之外，也喜欢看书，写一点日常杂文和心情分享，如果你感兴趣，也可以关注关注！
• 微信公众号：傲骄鹿先生

一、什么是分支？

在版本控制过程中，同时推进多个任务，为每个任务，我们就可以创建每个任务的单独分支。使用分支意味着程序员可以把自己的工作从开发主线上分离开来，开发自己分支的时候，不会影响主线分支的运行。对于初学者而言，分支可以简单理解为副本，一个分支就是一个单独的副本。（分支底层其实也是指针的引用）

分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。

现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

其他版本控制系统如SVN等都有分支管理，但是用过之后你会发现，这些版本控制系统创建和切换分支比蜗牛还慢，简直让人无法忍受，结果分支功能成了摆设，大家都不去用。

但Git的分支是与众不同的，无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件。

二、什么时候会产生合并冲突？

假如说我们目前我们有两个分支master和hot_fix，目前两个分支的内容是一样的。

假设master分支修改了它的工作区的apple.txt文件，并做了提交。而hot_fix分支也修改了它的工作区的apple.txt文件，并做了提交。

这里假设master分支修改的内容和hot_fix分支修改的内容不一样。

这个时候，无论是master分支想要合并hot_fix分支，还是hot_fix分支想要合并master分支，都会合并冲突。

1. 这里我们先在master分支，修改apple.txt文件

修改的内容如下

接下来，我们切换到hot_fix分支，对apple.txt修改

修改内容如下：

这里我们注意的是一个是修改的原来版本的第7行，一个是修改的原来版本的第8行。

这里可以把master合并到hot_fix分支上，也可以把hot_fix分支合并到master分支上。

这里我就把master分支合并到hot_fix分支上

可以看到这个给出的提示，自动合并出现冲突；让我们修改冲突，然后再提交合并。

这个时候，处于合并状态，我们可以看一下

git提示，我们有未完成的合并，需要我修改冲突后，增加并提交这个文件。

而且，因为现在是一个状态（合并）没有执行完毕，是不能进入下一个状态的。可以看到我想要切换到master分支，就失败了。

三、解决冲突

冲突是因为我们两个不同版本合并时，两个版本都有的文件被修改了。

这个时候就需要两版本的作者，讨论一下，需要怎么做。

我们看一下合并失败的文件。

<<<<<< HEAD，到=======之间的内容就是本分支中最新版本中和要求合并的分支冲突的地方。

========，到>>>>>>> master之间的内容是master分支要求合并的内容和本分支HEAD指向的本地库之间的冲突。

如何修改这个文件？

首先，肯定是要删除提示信息，这三行。
同时根据两个版本作者讨论的结果，对文件内容进行修改到满意程度。最后再次提交。

假设我们修改的结果是对这两个修改都进行保留。

提交解决合并冲突

可以看到这里对合并冲突的提交不能有文件名，也就是合并冲突，如果有多个文件有冲突，必须都解决，这次的提交会是所有冲突都解决的提交。

git有log有一个非常有用的命令。可以用来查看，目前这个项目中版本的变化。同时可以以图像化的方式显示出分支创建后的版本迭代，以及最终的合并过程。

注：中间部分由缺失是因为我创建了其它分支，后面又删除了。