解决冲突
第一步:删除冲突部分
首先打开冲突文件ProgramAfile1.txt,可以看到典型的冲突文件显示方式
箭头<<<与>>>范围内表示的是发生冲突的位置,B是程序员B对ProgramAfile1.txt所做的修改,A为程序员A和远程仓库C中ProgramAfile1.txt的内容
假如这时候AB两位程序员经过了协商,绝对保留B所做的修改,则需要删除其余多余的行
注:vim指令补充:通过esc进入命令行模式,双击d单独删除某行,dG删除光标所在行以及其下所有行的内容
第二步:进行提交
再次查看一下状态
发现文件处于工作区,git提醒我们要使用git add指令将已经解决冲突的文件提交到暂存区
紧跟着提醒你执行git commit,我们照做执行git commit,然后git自动生成了一个commit信息文件,保存即可,再查看一下状态,即解决冲突
这时候我们git commit时候,再git status时显示已经解决冲突,也显示出你比远程的origin/master多了2次提交
解密为何快2个版本
我们先对比下两个仓库的版本号看看
- 可以看出现在
AC两个的仓库仍然是一样的 B第一次比AC快是因为B自己对文件进行了修改与提交,所以比AC更快1个版本- 然后
B想push,但因为与C发生冲突,为了解决冲突,所以修改并提交了冲突文件,所以又快了1个版本
图文讲解
- 首先
A在本地仓库修改了ProgramAfile1.txt,并进行了push到了C - 此时
B同样也在本地仓库进行了一次提交修改ProgramAfile1.txt,但因为修改的是与A同一个文件的同一个地方,所以push失败,只能进行pull到B本地进行手动修改 - 当
B执行pull操作时,将远程仓库拉取到本地后,由于发生冲突,所以暂时不会将origin/master的指向更新到最新提交,随后,在B中手动解决冲突并合并后,B的状态变为
可以看到解决冲突,手动合并后,B已经往前更新了两次提交,而此时的origin/master仍然指向提交1st
我们试试B仓库执行git push
发现push成功,并且BC已经相同了
我们看看A试试
这时候A则慢了BC两个版本
三个仓库状态图如下:
在实际开发当中,难免会出现多个人修改了同一个文件的情况,在进行手动合并的过程中一定要与对方协商应该如何合并,如何舍取,而不是直接覆盖
