当前位置:   article > 正文

Git代码冲突解决步骤_代码解决冲突

代码解决冲突

  今天讨论下实际开发中有关版本控制的问题。在多人协作编码时,使用Git版本管理,在提交代码时可能会遇到冲突的情况,这里讨论下冲突的解决步骤。

  首先在本地创建一个测试项目“Test”,并与远程代码库进行关联,此步骤省略。

1、创建代码的用户命名为“用户1”。代码库内只有一个文本文件“Test.txt”,文件内容如下图:
在这里插入图片描述

提交本地代码,查看提交记录
在这里插入图片描述

将本地代码推送到远程库,结果如下:
在这里插入图片描述

2、另一个开发者命名为“用户2”。他从远程代码库克隆项目到本地,如下图:
在这里插入图片描述

此时文件内容和“用户1”本地内容相同:
在这里插入图片描述

3、“用户2”修改本地文件,增加一行数据(“用户2第1次提交:67890”),并在本地进行提交:
在这里插入图片描述

“用户2”将本地代码提交到远程库,结果如下:
在这里插入图片描述

4、“用户1 ”通过某种方式得知“用户2”修改了代码,他在本地拉取远程库代码,可以看到文件变化状态:
在这里插入图片描述

“用户1”此时查看本地文件内容,与“用户2”提交内容一致:
在这里插入图片描述

此过程未发生代码冲突,因为“用户1”完全信任“用户2”的修改,直接拉取了远程代码库。
接下来两个用户同时对同一个文件的相同位置进行修改,造成冲突。

冲突解决方式一:

1、在原来项目的基础上,“用户1”继续对本地文件进行修改,修改后内容为:
在这里插入图片描述

将代码提交到本地库:
在这里插入图片描述

并将代码推送到远程库:
在这里插入图片描述

2、此时“用户2”也在本地修改代码,修改内容为:
在这里插入图片描述

“用户2”也将代码提交到本地库:
在这里插入图片描述

但是在推送远程库时发生错误,提示如下:
在这里插入图片描述

错误原因是远程库包含了本地库没有的内容,也就是“用户1”第二次推送的内容。Git提示我们要先拉取远程修改并整合后再进行推送。

3、“用户2”尝试拉取远程库内容:
在这里插入图片描述

提示显示存在冲突,此时进入“MERGING”状态,如下图:
在这里插入图片描述

4、通过命令查看当前状态,显示同时修改的文件名“Test.txt”
在这里插入图片描述

5、也可以通过命令查看同时被修改的文件差异,其中“HEAD”指向的是当前用户提交的内容,分割线下方是其他用户提交的差异内容。
在这里插入图片描述

6、通过查看本地文件也能看到相同的结果
在这里插入图片描述

7、此时需要当前用户手动解决冲突,即手动删除不想被提交的代码,如下图我们选择保留“用户2”的提交,将多余代码删除。
在这里插入图片描述

8、待文件修改完成后,再次执行提交动作,包含“add”,“commit”两步操作,提交后查看本地库记录。
在这里插入图片描述

可以看到提交记录中多了一次合并提交(图中e2f2402节点),两位用户的冲突代码形成并列关系的两个节点。

9、本地提交完成后即可推送远程代码,至此冲突解决:
在这里插入图片描述

10、查看远程库代码和提交记录如下图:
在这里插入图片描述
在这里插入图片描述

冲突解决方式二:

以上是第一种方式解决提交冲突,在此基础上演示下第二种解决方式。
1、“用户2”在提交完成后,本地进行第三次修改,修改内容如下:
在这里插入图片描述

2、然后执行正常的提交和推送远程的步骤,远程库修改后如下:
在这里插入图片描述

3、“用户1”在本地也修改同样的位置,但只是部分代码与“用户2”本次提交不同:
在这里插入图片描述

4、与前述步骤类似,“用户1”本地提交完成后,推送远程库会失败报错,错误原因同样是远程库有本地不存在的内容。如下两图:
在这里插入图片描述
在这里插入图片描述

5、此时按照“方式一”的方法拉取远程代码,但拉取时增加参数“–rebase”,拉取后显示存在冲突。
在这里插入图片描述

此时本地库变成“REBASE”状态。
在这里插入图片描述

6、通过查看本地记录可以看到两次冲突提交(e6e4638和5943de2)。
在这里插入图片描述

7、查看本地状态也会显示同时修改同一文件:
在这里插入图片描述

8、查看代码差异可以看到只有一行冲突,相同的代码不会影响。
在这里插入图片描述

9、本地修改冲突文件
在这里插入图片描述

10、本地重新提交
在这里插入图片描述

11、查看本地提交记录,提交顺序分别是“用户1第3次提交”,“用户2第3次提交”,“用户1第3次提交,解决冲突”。但此时仍处于“REBASE”状态,需要解决此状态才能推送远程。
在这里插入图片描述

12、查看本地状态,此时处于一个正在编辑的提交,提示我们可以继续执行rebase命令。
在这里插入图片描述

13、执行命令“git rebase --continue”,状态显示已完成,此时主分支不再是“REBASE”状态。
在这里插入图片描述

14、再次查看本地提交记录。对比前述第11步,可以看到“用户1的第3次提交”这个节点消失了,整个分支变成了顺序状态,而当前用户的本次提交(为了表达清晰,命名为“用户1第3次提交,解决冲突”)变成了整个分支的最新提交。
在这里插入图片描述

15、经过以上步骤后再重新推送远程库,同时检查远程库代码完全正常。代码冲突得以解决。
在这里插入图片描述
在这里插入图片描述

总结:

方式一:会显示所有merge节点,合并冲突后产生一次新的合并提交
1.本地修改代码后按步骤提交
2.推送远程代码失败,需拉取远程库代码
3.使用拉取命令“git pull origin master”
4.找到冲突代码人工修改
5.重新执行提交动作,
(1)git add .
(2)git commit -m “xxx”
(3)git push origin master

方式二:不显示merge节点,合并后把当前提交放在所有提交之上
1.本地修改代码后按步骤提交
2.推送远程代码失败,需拉取远程库代码
3.使用拉取命令“git pull --rebase origin master”
4.找到冲突代码人工修改
5.重新执行提交动作,
(1)git add .
(2)git commit -m “xxx”
(3)git rebase --continue
(4)git push origin master

 对于何时选用哪种合并方式,目前还没有研究清楚。据网上说法,要看项目具体要求,以上示例中只有一个主分支,没有开发分支,一般不建议在主分支上使用“–rebase”。针对这个问题以后再做详细讨论。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/小丑西瓜9/article/detail/321306
推荐阅读
相关标签
  

闽ICP备14008679号