1

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

我正在尝试使用开发分支重新设置功能分支：

git checkout myFeatureBranch
git rebase developBranch

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

git mergetool

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

我试过git gc --aggressive和git fsck --full。git gc 报告完全没有问题，并且 git fsck 有很多悬空的东西，但没有错误或缺少信息。

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

什么是错误的任何其他可能性？

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

无论问题是什么，它确实出现在我们的主远程仓库中，因为新克隆出现了相同的变基问题。

谢谢你的帮助。

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
4

3 回答 3

5

你遇到了 git 的重命名检测。

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

  1. Rebase 使用合并机制。

  2. 在合并（例如，合并feature到master）中，您会说“我所在的分支master，，是'我们的'代码，而我正在合并的分支feature，，是'他们的'代码”。

当您变基代码时，“我们的”一侧是您要变基的代码，而“他们的”代码是您要变基的代码，即您自己的代码。实际上，“边”被交换了。（请参阅-m、-s和-X参数git rebase以及关于交换边的注释。）

在合并机制内部，使用默认 ( recursive) 策略，git 认为“我们的” （即myFile1.h来自) . 所以它试图合并错误的文件。developmyOtherFile.cmyFile1.h

转到git merge文档，注意您可以传递给的选项recursive。最重要的可能是rename-threshold=<n>。因此，您可以通过-X rename-threshold=100（或任何足够高于 50 的数字）。我自己从来没有真正遇到过这个问题，但这似乎应该可以解决问题。

于 2013-10-29T21:07:54.733 回答
2

git rebase -p develop似乎成功了。感谢jthill。

我还没有尝试过torek的答案，但出于好奇，我也计划对此进行探索。

于 2013-10-30T14:12:04.220 回答
0

为什么历史上的合并会产生任何影响？

Rebase 是一种降噪工具，可将浪费时间的冗余排除在公开历史之外。一旦你完成了该写的，rebase就是“写该读的”帮手。对于一个逐个打击你只需合并，当这会使读者的工作不必要地复杂化时，一对一的线性[化]几乎总是足够好和容易，所以这就是默认情况下 rebase 所尝试的。如果结果不是那么容易，可以使用-iand-p和--interactiveand--preserve-merges来帮助进行更复杂的编辑。

于 2013-10-30T18:41:36.480 回答