Git基础之合并解决冲突, 解决vs报错: 遇到合并冲突标记

在编写netMarketing类库时,经常遇到合并冲突.

image.png

打开冲突的文件, 看到是下面这样的:

image.png

image.png

image.png

第一个标记<<<<<<< HEAD后的内容源于当前分支。

第二个标记>>>>>>> 16bfefa465b369a7f46d090072d9e638bc951db9

,Git 会告诉我们这些改动是从哪里(哪个分支)来的。

然后有两个冲突的改动会被 “=======” 分割起来。 


如果是在本地仓库里面打开工程, 你会发现, 即使有上面的冲突存在, 程序依然是可以正确运行的.

但是如果你在本地仓库目录外面打开一个工程, 然后把仓库的工程添加进去, 再编译工程, 会出现第一张图片所示的"遇到合并冲突标记"的错误.


经过反复尝试, 摸索出了解决方法分为两部分:


(1) 先人工的把上面的每个有冲突的AssemblyInfo.cs 人工删除除master之外的分支, 即保留“=======”分隔的上面部分.

(2) 此时如果再编译,会出现 

 Files 的值“ < < < < < < < .***”无效。路径中具有非法字符。

这时候, 需要把UserUi, sharClass, netMarketing三个目录下的Obj目录中的工程名.csproj.***的文件全部删除

image.png

(3) 再重新编译就OK了!


解决这个问题时, 发现了一个知识盲区, 原来从来不知道这个Obj是干嘛用的. 查了下网络资料, 说明如下:


1.bin 

    bin目录用来保存项目生成后程序集,它有Debug和Release两个版本,分别对应的文件夹为bin/Debug和bin/Release,这个文件夹是默认的输出路径,我们可以通过:项目属性—>配置属性—>输出路径来修改。

2.obj
    obj目录是用来保存每个模块的编译结果,在.NET中,编译是分模块进行的,编译整个完成后会合并为一个.DLL或.EXE保存到bin目录下。因为每次编译时默认都是采用增量编译,即只重新编译改变了的模块,obj保存每个模块的编译结果,用来加快编译速度。是否采用增量编译,可以通过:项目属性—>配置属性—>高级—>增量编译来设置。




关于本例中冲突产生的原因,  有一篇文章讲得比较好, 引用如下:


知识储备

要解决问题之前,先要弄清楚git合并代码做了哪些事。git拉回(pull)操作实际是有两个步骤组成,一个是获取(fetch),一个是合并(merge)操作,即:

git pull = git fetch + git merge

根据合并操作是否遇到冲突,自动合并有以下三种情况:

1修改不同的文件

2修改相同文件的不同地方

3同时修改文件名和文件内容

场景一

修改不同文件:

用户D和用户L在本地提交中修改了不同的文件,如果用户D将改动推送到服务器后,用户L再推送就会遇到非快进式推送错误。

非快进推送(non-fast-forwardupdates)错误是在远程版本库和当前版本库内容不一致时推送所致,引起原因一般为在多成员协同工作下,其他用户在当前用户版本库上次commit和本次commit之间向远程版本库执行了推送。


具体错误过程如下:

假如用户D修改了mock文件夹下的开屏广告.txt文件,提交并推送至远端。

image.png

同时用户L修改了mock文件夹下的原生广告.txt文件并提交。

image.png

这时用户L在push时会遇到非快进式推送错误而终止。

image.png

下面操作可以实现合并并推送。

image.png


以上是这种问题的说明.

=====================================================================================

博主在维护类库netMarketing类时, 经常遇到上述问题, 我把某次的解决过程说明如下:

错误截图如下:

image.png

git status指令告诉了状态不对的原因, 还有解决方法的提示
     image.png

依据提示执行  git add *
然后再执行 git status,  发现状态就没有异常了.

image.png

接下来执行 git push -u origin master 
可以看到上传成功了!

image.png

=====================================================================================


场景二

修改相同文件的不同区域:

当用户D和L在本地提交中分别修改了feature文件夹下或者mock文件下的相同文件时仍可以提交并成功合并。具体操作同上步骤。

场景三。

同时更改文件名和文件内容:

用户D将feature文件名修改为feature1,用户L针对重命名前的feature文件进行修改,Git对于此类冲突能够很好地处理,可以自动解决冲突实现自动合并。

具体操作过程如下:

确保D用户和L用户的本地版本库和远端版本库状态一致,先分别对两个用户的本地版本库执行 $git pull 拉回操作。

用户D在自己的工作区将feature文件进行重命名,并提交推送至远端。

image.png

用户L在自己的工作区修改了feature文件,在文件的最后插入内容,并本地提交。

image.png

用户L推送合并后的本地版本库到共享版本库。

image.png

总结

代码冲突是多人协作开发过程中最常见的问题,一旦解决不好,会引发丢失代码或者业务功能异常等问题,所以在系统功能设计上,要做到功能解耦,并且不同的功能在不同的文件中实现;在开发过程中,也要养成良好的开发习惯,比如D和L都在修改feature文件或config文件,如果两人都没有定期pull代码的习惯,那么push代码时就很容易遇到冲突。所以完成一个功能或者解决一个问题及时commit & push代码,有冲突尽早解决。



本文出自勇哥的网站《少有人走的路》wwww.skcircle.com,转载请注明出处!讨论可扫码加群:

发表评论:

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。

会员中心
搜索
«    2024年4月    »
1234567
891011121314
15161718192021
22232425262728
2930
网站分类
标签列表
最新留言
    热门文章 | 热评文章 | 随机文章
文章归档
友情链接
  • 订阅本站的 RSS 2.0 新闻聚合
  • 扫描加本站机器视觉QQ群,验证答案为:halcon勇哥的机器视觉
  • 点击查阅微信群二维码
  • 扫描加勇哥的非标自动化群,验证答案:C#/C++/VB勇哥的非标自动化群
  • 扫描加站长微信:站长微信:abc496103864
  • 扫描加站长QQ:
  • 扫描赞赏本站:
  • 留言板:

Powered By Z-BlogPHP 1.7.2

Copyright Your skcircle.com Rights Reserved.

鄂ICP备18008319号


站长QQ:496103864 微信:abc496103864