git 合并冲突_合并冲突 - 每天三分钟玩转Git（三）

“ 五四青年节快乐哦 ——编程三分钟”

我们多人合作提交代码的时候，常常会出现两个人同时改了某个代码文件，这个时候你一拉代码就傻眼了！就连Git自己也不知道应该保存哪一份文件，在此时就需要一个超级英雄出现拯救世界，他享有最高的决定权，而那个人就是你了。

入门参考下两篇文章

Git 版本控制，看这篇就够了 （一）

Git 版本控制，看这篇就够了 （二）基础篇

01

—

合并同一个分支的冲突

通常这种情况就发生了我们拉远程的代码的时候发生的本地代码与远程同时修改了一个地方，这个时候就需要决定保留哪部分代码舍弃哪部分代码。

为了产生一个冲突，我在另一个地方向远程仓库提交了代码，更改share_file.txt文件，加了一行内容tom add for merge

本地修改同一个文件加了一行pzqu add for merge，并提交到本地，这样一来，本地和远程仓库的同一个文件就不一样了，一会拉代码一定会产生一个冲突。效果如下：

1. 一般rebase或pull冲突的时候，都会出现提示，然后git status会出现上图图示
2. 这个时候不可以进行任何分支切换和commit操作，按照他提示进行处理
3. git status提示哪个文件是都被修改的，both modified，然后使用编辑器修改该文件，解决冲突
4. 解决完成后，git add 添加该冲突文件
5. git rebase --continue，并更新commit message，完成整个rebase流程

我们来看看这个冲突的文件：

Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们修改如下后保存：

git add再git rebase --continue后完成rebase，效果如下，再push的远程仓库即可

02

—

合并不同分支的冲突

想像一下，要是我们只用主分支来写代码，在和同事开发不同功能的时候交叉提交到远程的主线上，要是产品突然不要这个功能了，回退起来就非常的困难，不仅仅要去一个一个的找哪个提交是属于这个功能，还要小心翼翼的处理一遍全部的冲突。

用分支就不会有这么多事情，在自己的分支上干活，等全部开发完成，再一次性的合并到主分支上，这样我们既可从分支上知道一个人的开发进度，又不影响大家干活，是不是很 方便呢？

关于怎么创建分支与切换分支见上一次推送,这里只讨论合并时产生的冲突的情况，我们已经基于master分支创建了一个dev/pzqu分支

切换到master分支，加一行master add for merge并提交，文件内容如下：

切换到dev/pzqu分支，向share_file.txt加入一行dev/pzqu add for merge并提交，现在share_file.txt内容如下：

现在两个分支的同一个文件内容不一样了，现在我们在dev/pzqu分支上进行合并：

上图出现了一个冲突，是我们意料之中的，修改share_file.txt文件，解决此冲突：

冲突解决也提交了，看看我们现在的分支内容：

上图我们可以看到：

1. master分支比远程origin/master分支多一次提交，dev/pzqu分支由于是基于origin/master分支，合并了master分支的提交和当前dev/pzqu分支的提交，超出本地master两个提交，致此我们把master合并到dev/pzqu的操作就完成了。
2. 通常我们开一个新的开发分支是为了在自己的分支上写代码，方便提交也不会把主线弄乱。

现在我们用同样的方法将dev/pzqu合并到master分支，然后把两个分支都提交到远程。

1. 切换到master分支
2. 合并dev/pzqu到master分支
3. master推到远程仓库
4. 如果dev/pzqu要保留，就可以推送到远程仓库。

现在我们可以看到全部的分支都在一起了，强迫症都舒服了。

小结

本文阅读结束以后，我们学会了

1. 处理远程同步代码过来以后和本地产生的冲突
2. 学会使用自己的开发分支，并且处理不同分支之间的合并操作

PS： 冲突是一个非常好的机制，方式两个人没沟通好都同时修复一个Bug获取同时写的某个功能，一发生冲突一下子就发现啦！

下回预告：

在之后的推送里，我会不断吸取大家的建议，让大家可以用最短的碎片时间看完一篇文章，学到一个知识点，真正的体现出编程三分钟的魅力。

下次给大家介绍一个骚操作，你正在好好的写代码，突然线上有一个十万火急的Bug，必须要放下手头的工作，赶紧处理Bug再提交上去要怎么做呢？如果有兴趣可以在评论区与我互动哦。

敬请期待哦~！

---

长按图片识别二维码即可关注

编程三分钟，用最通俗易懂的方式聊技术