git什么情况下会产生冲突以及如何优雅的解决冲突

最新推荐文章于 2024-06-07 08:45:00 发布

copbint

最新推荐文章于 2024-06-07 08:45:00 发布

阅读量1.8w

点赞数 7

分类专栏：工具—IDE—环境搭建

本文链接：https://blog.csdn.net/qq_31567335/article/details/85037945

版权

工具—IDE—环境搭建专栏收录该内容

20 篇文章 0 订阅

订阅专栏

制造冲突

在github上创建一个仓库。
在本地两个文件夹分别clone同一仓库。称之为仓库A，仓库B。
在仓库A修改文件，提交到远端。
git add -A
git commit -m “2aaaa”
git push origin master:master
修改的文件：test.txt
1test
2aaaa
在仓库B修改同一文件的同一行：test.txt
1test
2bbbb
同样保存修改后，尝试提交到远端，发现冲突了，导致无法提交到远端：

既然冲突了，就必须解决冲突，解决冲突有两种方式：
rebase, merge。主要区别是合并之后commit的个数不一样：rebase保留原分支上的每个commit，merge只会生成一个commit。

解决冲突

方法1：使用rebase合并分支

git fetch
下载所有分支的最新代码
git rebase origin/master(以origin/master分支为基线，合入master分支的修改到origin/master。)
当然，会提示冲突：

可以看出冲突的文件是test.txt。
打开test.txt，可以看到冲突的内容：
```
1test
<<<<<<< 1041dfeabc9e796478294adbcf72aa61f64f8f84
2aaaa
=======
2bbbb
>>>>>>> 2bbbb
```

留下想保存的内容，其他删除掉。就OK了。

也可以用git提供的左右比较的方式进行编辑，解决冲突：
选中冲突的文件->右击->TortoiseGit->Edit confilicts:

git add -A
冲突解决完成之后，提交修改
git rebase --continue
继续合并。合并的过程中，还有可能产生冲突。解决方法同上。
git push origin master:refs/for/master
冲突解决完之后。推送到远端服务器

用一个图概括rebase解决冲突的前后变化：
解决冲突前：

解决冲突后：

方法2:使用merge合并分支

git fetch
下载所有分支的最新代码
git checkout origin/master
直接切到远端的master分支
git merge master
将master分支的修改合入
提示冲突：

和rebase一样，手动解决冲突。

git add -A;git commit
提交修改。合并完成。
合并完成之后，origin/master,master分支指向的地方都未发生改变：
git push origin HEAD:refs/for/master
推送到远端服务器
从上面的图可以看出，master分支并未指向最新，所以不能使用:
git push origin master:refs/for/master
如果要使用，则可以先将master分支指向最新的commit：
git checkout -B master HEAD
然后：
git push origin master:refs/for/master

用一个图概括merge解决冲突的前后变化：
解决冲突前：

解决冲突后：

cherry-pick冲突及解决冲突

在gerrit的界面上使用cherry-pick是在服务端进行操作的，完全不涉及本地分支。
cherry-pick的原理可以简单理解为：
将本commit与其父commit之间的差异（patch）应用到另一个分支上。
所以说，如果如果patch对应的源文件对应的行在另一个分支已经被改变了，那么就无法成功应用patch，会提示冲突。gerrit未提供远程解决冲突的能力，必须要在本地手动解决冲突。
假如要将master某个commit提交到dev分支，操作流程如下：

git fetch
下载所有分支的最新代码
git checkout -B dev origin/dev
直接用远端的dev分支覆盖本地的dev分支，并切换到dev分支
git cheery-pick commitId
将commitId对应的commit应用到dev分支上来。
如果产生了冲突，则需要和上面讲到的一样，手动解决冲突。
git add -A;git commit
冲突解决完之后，提交修改
git puhs origin dev:refs/for/dev
提交到远端

git pull

网上搜到的解释都是说pull是fetch+merge操作的合并。
那么到底是谁merge谁，merge的过程中是否会产生新的提交，产生的提交push的时候又是否会推送到远端呢？
实践一下：

1. origin/master比master多一个节点

此时使用git pull拉取分支时，本地master直接更新为和远端master一样。

2. orgin/master 和master分叉以后，各自多了一个节点,并且无冲突

然后进行pull操作，会发现在本地的master分支上形成了一个新的提交，对应的message为：Merge branch ‘master’ of https://github.com/copbint/blogs
origin/master并未发生改变。
图示：

将master推送到远端。
远端生成了一个新的提交。
由于master指向的节点，是orgin/master指向的节点的子节点，并无分叉，所以一定不会出现冲突。

再执行git pull将远端最新代码取下来，master和origin/master都指向了最新的提交。即D‘

3. orgin/master 和master分叉以后，各自多了一个节点,有冲突

执行，git pull报冲突：
此时必须手动解决冲突。然后提交修改。此时会产生一个新的commit。
和上面的例子唯一的区别就是需要手动解决冲突，然后提交commit。

如果此时，再提交一个新的commit，然后推送到远端。会推送几个commit呢？

实践了一下，远端产生了两个提交。

4. 总结

git pull就是先获取远端分支，然后将对应的远端分支merge到本地分支上来。
如果本地分支和远端分支已经分叉，则会在本地分支上产生一个新的提交。
如果有冲突，则需要手动解决冲突。

其他

github什么情况下会产生冲突呢？测试了一番，只有修改了同一个文件，就会产生冲突。
测试的方法包括：

修改同一文件间隔很远的不同行
修改同一文件，修改的内容完全一样

都提示冲突。但是在本地使用rebase，merge合并的时候，无需要手动解决冲突，直接就自动合并完成了。
这一点，gerrit似乎要机智一些，只要不是修改了文件的同一行，就可以自动合入。

在某个不用的服务上创建两个test分支，用完之后可以删除掉。
test_MASTER_test
test_DEV_test

gerrit的展示不是很准确，commit的内容并不在当前分支也展示出来。而真正改变当前分支的merge …对应commit的改变却并没有提现出来。

copbint

关注

7
点赞
踩
53

收藏

觉得还不错? 一键收藏
0
评论
git什么情况下会产生冲突以及如何优雅的解决冲突

写在前面：现在还只是杂乱的记录，部分内容在公司，需要时间手工搬运出来…普通合入引发的冲突方法1(推荐)：使用rebasegit fetch下载所有分支的最新的远端分支（看一下如何下载某个特定分支）git rebase origin/master以origin/master分支为基线，合入master分支的修改。手动解决冲突git add -A;git rebase --cont...
复制链接

扫一扫

专栏目录