git 提交冲突怎么办

Posted 2023-05-05

参考技术A 冲突的产生
很多命令都可能出现冲突，但从根本上来讲，都是merge 和 patch（应用补丁）时产生冲突。
而rebase就是重新设置基准，然后应用补丁的过程，所以也会冲突。
git pull会自动merge，repo sync会自动rebase，所以git pull和repo sync也会产生冲突。当然git rebase就更不用说了。
冲突的类型
逻辑冲突

git自动处理（合并/应用补丁）成功，但是逻辑上是有问题的。
比如另外一个人修改了文件名，但我还使用老的文件名，这种情况下自动处理是能成功的，但实际上是有问题的。
又比如，函数返回值含义变化，但我还使用老的含义，这种情况自动处理成功，但可能隐藏着重大BUG。这种问题，主要通过自动化测试来保障。所以最好是能够写出比较完备的自动化测试用例。
这种冲突的解决，就是做一次BUG修正。不是真正解决git报告的冲突。
内容冲突

两个用户修改了同一个文件的同一块区域，git会报告内容冲突。我们常见的都是这种，后面的解决办法也主要针对这种冲突。
树冲突

文件名修改造成的冲突，称为树冲突。
比如，a用户把文件改名为a.c，b用户把同一个文件改名为b.c，那么b将这两个commit合并时，会产生冲突。
$ git status
added by us: b.c
both deleted: origin-name.c
added by them: a.c
如果最终确定用b.c，那么解决办法如下：
git rm a.c
git rm origin-name.c
git add b.c
git commit
执行前面两个git rm时，会告警“file-name : needs merge”，可以不必理会。

树冲突也可以用git mergetool来解决，但整个解决过程是在交互式问答中完成的，用d 删除不要的文件，用c保留需要的文件。
最后执行git commit提交即可。
内容冲突的解决办法
发现冲突

一般来讲，出现冲突时都会有“CONFLICT”字样：
$ git pull
Auto-merging test.txt
CONFLICT (content): Merge conflict in test.txt
Automatic merge failed; fix conflicts and then commit the result.

但是，也有例外，repo sync的报错，可能并不是直接提示冲突，而是下面这样：
error: project mini/sample
注：无论是否存在冲突，只要本地修改不是基于服务器最新的，它都可能报告这个错误，解决方法都是一样。

这个时候，需要进入报错的项目（git库）目录，然后执行git rebase解决：
git rebase remote-branch-name
冲突解决的一般过程

merge/patch的冲突解决

先编辑冲突，然后git commit提交。
注：对于git来讲，编辑冲突跟平时的修改代码没什么差异。修改完成后，都是要把修改添加到缓存，然后commit。
rebase的冲突解决

rebase的冲突解决过程，就是解决每个应用补丁冲突的过程。
解决完一个补丁应用的冲突后，执行下面命令标记冲突已解决（也就是把修改内容加入缓存）：
git add -u
注：-u 表示把所有已track的文件的新的修改加入缓存，但不加入新的文件。

然后执行下面命令继续rebase：
git rebase --continue
有冲突继续解决，重复这这些步骤，直到rebase完成。

如果中间遇到某个补丁不需要应用，可以用下面命令忽略：
git rebase --skip

如果想回到rebase执行之前的状态，可以执行：
git rebase --abort

注：rebase之后，不需要执行commit，也不存在新的修改需要提交，都是git自动完成。
编辑冲突的方法

直接编辑冲突文件

冲突产生后，文件系统中冲突了的文件（这里是test.txt）里面的内容会显示为类似下面这样：
a123
<<<<<<< HEAD
b789
=======
b45678910
>>>>>>> 6853e5ff961e684d3a6c02d4d06183b5ff330dcc
c
其中：冲突标记<<<<<<< （7个<）与=======之间的内容是我的修改，=======与>>>>>>>之间的内容是别人的修改。
此时，还没有任何其它垃圾文件产生。

最简单的编辑冲突的办法，就是直接编辑冲突了的文件（test.txt），把冲突标记删掉，把冲突解决正确。

如何找出导致冲突的 Git 提交？

【中文标题】如何找出导致冲突的 Git 提交？

【英文标题】：How can I find out which Git commits cause conflicts?

【发布时间】：2013-08-12 08:15:51

【问题描述】：

我正在将上游更改合并到我的项目中，最近有很多提交造成了很多合并冲突。一次解决所有问题是没有意义的。

如何找出哪些提交会造成冲突？以下任何一项都可以接受：

一种让 Git 在发现冲突后立即停止合并的方法 一种让 Git 按时间顺序列出所有冲突提交的方法 任何其他可以让我按时间顺序逐一解决冲突的方法，不涉及一次合并几个提交以希望偶然发现冲突

【问题讨论】：

Git 与 svn 有点不同。它尝试一次合并所有提交。您可以尝试交互式 rebase，它会一一应用提交，并在发现冲突时立即失败。

【参考方案1】：

你有什么理由不想使用rebase（非交互方式）与上游分支中的更改同步？如果每次提交发生冲突，它将停止，然后您可以在解决后恢复 rebase。这就像增量合并，它直接内置在 Git 中，不需要外部插件/工具：

git fetch <remote>
git rebase <remote>/<upstream-branch>
# Conflict on commit X, resolve conflict, then continue the rebase
git rebase --continue

关于强制推送重写提交的警告

当然，请注意，重新定位本地分支会更改其提交的 sha ID。如果您已经将要变基的提交推送到远程，那么您需要强制推送新提交以覆盖旧提交，如果您与其他人共享您的分支，这可能会造成潜在问题.您可以在以下位置了解有关这些问题的更多信息：

Pro Git § 3.6 Git Branching - Rebasing - The Perils of Rebasing

【讨论】：

rebase 很好，但你通常不想变基到已经推送到上游的分支（也可能不是强制提交）

@ideasman42 我不明白你所说的“强制提交”是什么意思。那应该是什么？ Git 中没有这样的命令或选项。你的意思是强制push？

对不起，我的意思是force-push

@ideasman42 同样，原始发布者正试图将上游更改合并到他的本地分支中。我的回答不会重新定位上游，它会将 未推送的本地分支 重新定位在上游之上。无需强制推送我的答案，因为它不会重新设置推送的提交。

@ideasman42 我误解了你的第一条评论吗？ “变基”到一个分支是什么意思？问题中也没有任何内容表明原始发布者已将他的本地更改推送到远程仓库。

【参考方案2】：

Michael Haggerty 还有一个名为git-mergemate 的工具，它有一个find-conflict 命令：

git-mergemate find-conflict BRANCH1..BRANCH2

使用二分法确定BRANCH2 上的最早提交 合并到BRANCH1 时会导致冲突。其实不要 保留任何合并。

git-mergemate find-conflict BRANCH1...BRANCH2

使用二分法查找一对最早的提交（一个来自 每个分支）不干净地合并。实际上不保留 任何合并。

git imerge 可用于执行增量合并并解决沿途的冲突，尽管它在 git-mergemate 中没有 find-conflicts 的等效项。

【讨论】：

在链接之后，似乎git-mergemate 实际上只是git imerge 的旧版本，VonC 在下面的回答中提出了建议。您可能应该编辑此答案以直接指向 imerge。

【参考方案3】：

您可以尝试git imerge：这将一个一个地应用您的提交，让您有机会增量进行变基（这意味着您可以开始变基、中断它、恢复它稍后！）。

您可以在此处查看Incremental merge vs. direct merge vs. rebase 之间的比较。

【讨论】：

git imerge 绝对有用。

谢谢！这也是一个很好的解决方案，但 git-mergemate 默认情况下完全符合我的想法。 git-imerge 也不错，但对我的需求来说有点过头了。

除了使用git imerge 之类的外部工具外，您还可以尝试cherry-picking 一系列修订来查看哪些冲突，一次一个（基本上就像rebase）。