赞
踩
这里说个题外话,现在网上有一种现象让我深恶痛绝,就是很多网友对别人所发的博文不加验证,便进行纯复制转发,我很想知道,转发了之后意义在哪?自己都没有去验证所转发的内容是否有效便进行纯复制转发,你们这是在污染网络环境,每次我遇到问题,网上一搜,搜索引擎前面几页一模一样的答案,而且还不是有效的博文,看着这些千篇一律的东西,真的是让我抓狂!!!小小吐槽一下
----------------------------------------------------------------------------------以下是正文-----------------------------------------------------------------------------------
上一篇文章(第1篇:Git和Gitea介绍、建立远程仓库以及推送和下拉代码)介绍了一些基础知识和基础操作,接下来我们来讲一下多人协同开发,提交代码时提示冲突,该如何处理?
在上一篇文章,我们已经建好了一个远程仓库GitTest,仓库里只推送过一个文件test.txt,该文件的全部内容是十个0。
现在,我们再建多一个measurement.txt文件,该文件的全部内容是十个哈,并提交到本地仓库的master分支上,同时推送到远程仓库的origin/master远程分支上,
我们先大概说一下,冲突是怎么产生的?为什么会报冲突?
我们先模拟一个场景:我(小林)和小马两个人协同开发一个GitTest项目。我和小马同时到远程仓库拉取代码,拉取代码后,此时我们各自的个人电脑上都有GitTest项目,项目里都只有两个文件,test.txt(文件的全部内容是十个0)和measurement.txt(文件的全部内容是十个哈)。
首先,小马对test.txt文件进行了修改,将文件内容修改成“0000000000小马”,并将本次修改推送至远程仓库,(我没有两个账号,所以小马的这些操作由我直接到远程仓库上修改,来模拟小马修改的推送)
此时,我并未拉取最新代码,我的个人电脑上的test.txt文件的文件内容依旧是“0000000000”。这个时候,我也对test.txt文件的内容进行修改,修改成“0000000000小林”,紧接着将其提交到本地仓库,再将其推送到远程仓库,这个时候是一定会报冲突的,
“Cancel”按钮一看就知道是什么意思,我就不用讲了吧,“Rebase”按钮先不管,后面讲版本回滚的时候再讲它,主要讲一下“Merge”按钮,Merge是合并的意思,我们先点一下这个按钮,会弹出以下红色圈中的窗体,
大伙看一下上图黄色圈中的字样,如果大伙有在命令提示符(Git Bash Here,类似于cmd,不过比cmd拥有更丰富的字体颜色)使用git merge命令,就有可能看过这些字样,大概说明一下,“<<<<<<< HEAD = = = = = = = >>>>>>> origin/master”是冲突标记符;“<<<<<<< HEAD”和“= = = = = = =”中间的内容是你此时准备推送的内容里发生冲突的部分;“= = = = = = =”和“>>>>>>> origin/master”中间的内容是远程仓库的内容里与你推送内容相冲突的部分。
假设你在命令提示符(Git Bash Here)里处理冲突,那就是先对两个内容(即0000000000小林和0000000000小马)进行取舍,最后把冲突标记符删掉就可以了。
但如果你是在开发集成软件IDEA上处理冲突,那就比较好操作了,IDEA特别人性化,它提供了各种可能性的快捷按钮,比如“Accept Yours”按钮、“Accept Theirs”按钮、“Merge…”按钮。我们主要讲一下“Merge…”按钮,我们先点一下,会弹出以下窗体,
我们的处理是,将中间窗口的内容更改成“0000000000小马林”,然后点击“Accept”按钮,会弹出以下小窗体,点击“Apply Changes and Mark Resolved”按钮,
此时,我们用git log命令查看一下,如下,
由此我们可以知道,此时我的工作区和本地仓库已经是最新提交了,内容为“0000000000小马林”,而远程仓库还不是最新提交,所以,我们现在要做的是,将我的本地仓库推送到远程仓库上便可以了,
首先,我和小马两个人先拉取最新的代码版本(即test.txt文件的文件内容是“0000000000小马林”,measurement.txt文件的文件内容是“哈哈哈哈哈哈哈哈哈哈”)。
接着,小马将test.txt文件的文件内容修改为“0000000000小马林 1111111111小马”,
此时,我并没有拉取最新代码,而是直接在我个人电脑上对measurement.txt文件进行修改,将其内容修改为“哈哈哈哈哈哈哈哈哈哈 1111111111小林”,
紧接着,我将其进行提交推送,它会提示代码冲突,
此时,我们点击“Merge”按钮,它就会帮我们直接合并,还会帮我们将其推送到远程仓库,没有第一种情况那么麻烦,不需要自己手动整合内容和手动再次推送。
为什么和第一种情况的处理方式有些许不同呢?这是因为第二种情况,我和小马修改的文件没有重叠,小马修改的是test.txt文件的文件内容,而我修改的是measurement.txt文件的文件内容,它们并没有产生二级冲突,所以合并相比第一种情况就比较简单。
详细点来说,冲突分两个级别,一级冲突和二级冲突(我个人自己定义的)。
当你准备进行推送的时候,如果推送前的版本不是此时远程仓库的最新版本,那么便会报一级冲突;报一级冲突的时候,进行合并操作,如果你推送的版本所涉及的文件与此时远程仓库修改了的文件没有重叠,便可以直接合并,如果重叠了,便会出现二级冲突,此时便需要你手动合并,即手动整合内容和手动再次推送。
至于为什么别人都说“push之前先pull”?有一个原因就是,他们都是以话传话,你问他为啥要这么做?他就会说以前带我的人就是这么说的,他们自己也不知道为什么。
你们看了我上面的例子,应该会有些感悟吧!其实“先pull再push”和“先push再pull”,往大了说,没啥差别,该报冲突照样报冲突,但往细了讲,确实“先pull再push”会更好一点,为什么这么说呢?请往下看!
假设在你准备push之前,已经有同事push上去一个新版本了,然后如果你是“先push再pull”,这个百分百会报冲突;但如果你是“先pull再push”,便不一定会报冲突,因为你进行pull的时候,如果是出现类似上面说的第二种情况的话(即双方修改的文件不重叠),那么人性化的IDEA便会将远程仓库的内容和你此时工作区所做的修改进行自动合并,并显示在你的工作区,然后你再进行push便可以了。
所以说,“先pull再push”相对于“先push再pull”来说,会方便好用一点,但是你不嫌麻烦的话,其实这两种是一样的。
|=============================================================================|
总结篇:Git使用总结
第1篇:Git和Gitea介绍、建立远程仓库以及推送和下拉代码
第2篇:提交代码时提示冲突如何处理(此时在这里)
第3篇:如何回退版本
|=============================================================================|
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。