Question

我认为在rebase期间合并冲突是一个非常奇怪的问题。

我正在尝试使用开发分支来修改功能分支：

git checkout myFeatureBranch
git rebase developBranch

现在git rebase报告冲突，我必须使用git mergetool来解决冲突。

git mergetool

Git mergetool声明了一个冲突的文件myFile1.h并且合并界面打开（对于同一个repo，问题出现在Linux或Windows / tortoisegit上）。我看到的是“他们的”文件完全是错误的文件myOtherFile.c，尽管“我的”文件正确显示myFile1.h。

我已尝试git gc --aggressive和git fsck --full。 git gc报告没有任何问题，git fsck有很多悬空的东西，但没有错误或缺少信息。

这是git数据库中的某种损坏，如果是这样，可以修复它吗？

出错的其他任何可能性？

我确实认为也许我可以将“我的”文件合并回自身（完全忽略所有不正确的“他们的”更改），也许这会清理问题，但我担心它也会使事情变得更糟。

无论问题是什么，它似乎都在我们的主远程仓库中，因为新克隆会出现相同的rebase问题。

感谢您的帮助。

带有一些编辑的

git config -l输出：

core.symlinks=false
core.autocrlf=input
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=true
pack.packsizelimit=2g
help.format=html
http.sslcainfo=/bin/curl-ca-bundle.crt
sendemail.smtpserver=/bin/msmtp.exe
diff.astextplain.textconv=astextplain
rebase.autosquash=true
core.autocrlf=true
core.excludesfile=<global exclude file>
user.name=Russell
user.email=<email address>
push.default=simple
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
core.hidedotfiles=dotGitOnly
remote.origin.url=<gituser@gitserver>
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
remote.origin.puttykeyfile=<key.ppk>
branch.master.remote=origin
branch.master.merge=refs/heads/master
branch.develop.remote=origin
branch.develop.merge=refs/heads/develop
branch.myFeatureBranch.remote=origin
branch.myFeatureBranch.merge=refs/heads/myFeatureBranch

Answer 1

你正在进行git的重命名检测。

首先，关于rebase的一些重要说明。

Rebase使用合并机制。
在合并中（例如，将feature合并到master），您会说“我所在的分支，master，是'我们的'代码和分支I合并，feature，是'他们的'代码“。

当您重新设置代码时，“我们的”是您将重新设置为的代码，而“他们的”代码是您要重新设置的代码 - 即您自己的代码。实际上，“边”被交换。（请参阅-m的{{1}}，-s和-X参数以及有关要交换的边的说明。）

在合并机制中，使用默认（git rebase）策略，git认为“我们的”recursive（即来自myFile1.h的那个）更像“他们的”{ {1}}（即您自己的文件版本）而不是“他们的”（即您的）develop。所以它试图合并错误的文件。

转到myOtherFile.c文档，请注意您可以传递给myFile1.h的选项。最重要的可能是git merge。因此，您可以传递recursive（或任何足够高于50的数字）。我自己从未真正遇到过这个问题，但这似乎应该可以解决这个问题。

Answer 2

git rebase -p develop似乎可以解决问题。感谢jthill。

我还没有尝试过torek的答案，但我也打算在好奇心的情况下探讨这个问题。

Answer 3

Why would merges in the history make any difference?

Rebase是一种减少噪音的工具，可以减少浪费时间的冗余。一旦你完成了值得写的东西，rebase就是“写下值得阅读的东西”的助手。对于一个逐个打击你只是合并，当这会不必要地使读者的工作复杂化时，线性[一化]一对一几乎总是足够好和容易，所以这就是rebase默认尝试的。如果结果不是那么容易，可以使用-i和-p，--interactive和--preserve-merges来帮助进行更复杂的编辑。

git rebase冲突合并错误的文件

3 个答案: