git如何解决代码冲突?

前言

在上一篇文章中说到,如果是单人进行开发的话,基本上不需要管代码代码冲突是个神马玩意。因为每次你都是接着自己之前的写,基本出现冲突的可能性还是蛮小的(不排除因为你用多个系统向同一个repo中进行push操作,其实这种情况也是蛮像多人协作开发的,对吧。)

借用之前的一张图片(表情包而已,我特别喜欢用这玩意),请拿出你的小零食,我们一起发车。

有好多东西用markdown写不出来,我就直接用html代码进行书写了,谁让我是业余前端狗呢?

开始

代码冲突是什么玩意

首先,不要怕。

对于很多人来说,合并时出现冲突是非常可怕的事,这就好像一不小心格式化了自己的硬盘一样。这也就是很多人不敢尝试去装系统的原因吧。格式化C盘的时候总是怕把整个盘的资料搞丢,其实按照程序来,出错的几率很小的。然而在使用git的时候,几乎永远不会出现你“再也回不去”从前的情况。你总是可以撤销一个合并操作,并且返回到冲突发生之前的状态。也就是说,你永远有机会放弃并重新开始。除非,除非,你做了删库到跑路的操作。

合并冲突不会破坏远程库

git merge conflict的时候,只会在自己的电脑上进行,不管怎么搞,都会在你本地的仓库进行,当然,有人在github上fork了你的仓库,给你发push request除外。

什么时候需要合并冲突

冲突就是代码的同一个部分出现了不一样的东西。举个例子: 比如,你在代码的第一行写了一个“宝大人最帅了”,然后用git push推送到了远程的仓库,另外一个人呢,他在第一行写了“宝大人超帅”,然后他写完之后,经过各种操作(add,commit),然后向远程的仓库进行推送的时候,git会检查一下代码,比对一下,看看有什么不同。当它看到同一个地方两个不同的结果后,它有些懵逼。它不知道宝大人到底是最帅还是超级帅,因为同一个地方不能有两个不同的代码,所以它就会问一下后提交的人:“宝大人是最帅还是超级帅?”同时拒绝这次提交。等这个人确定了之后,这两种有冲突的说法才能被“统一口径”,这个统一口径的过程,就叫做解冲突。其实更准确的解释叫合并冲突(merge conflict)

注意哦,不要把git想的特别傻,其实git是可以根据你代码的前后文进行merge操作的,只是当你明确的在同一个地方有了不同的代码,或者你修改了项目其他人的删除掉的那部分代码。git才会需要你进行手动解冲突的。

更专业的说法应该是没有必要说了吧。

开始演示解冲突

首先,我们先人造一个冲突。(因为以前解冲突的时候,没有截图)

红色箭头指向的部分就是我们制造的冲突。我碰到的多的冲突好像是40多条吧,说多了都是泪。

冲突图片

解决冲突第一步

将自己的代码先保存到一个安全的地方,代码为

	git stash 
Table of Contents