为什么git rebase会在新的分支特定文件上标记冲突

我现在有一个令人恼火的git rebase小问题

简要的总结是，文件上存在冲突，而不应该存在冲突。我读了很多关于SO的问题和文章，但我发现似乎没有什么能解决这样的问题

我所做的 我克隆了一个远程存储库，并一直使用git pull--rebase使其保持最新，然后将该本地主存储库重定为本地分支：

    git pull --rebase (on master)
    git checkout mybranch
    git rebase master mybranch
    <rebases cleanly>

我只是添加了一些新文件，直到几周前我才开始添加 获取远程或本地主分支上不存在的文件的某些合并冲突

    git pull --rebase (on master branch and successfully)
    git checkout mybranch
    git rebase master mybranch (conflicts in files that do not exist on master)

我从未将任何内容合并回本地或远程

在我添加的大约100个文件中，基本上有4个文件不断出现冲突，在重新设置基址期间，它们希望一次又一次地以相同的差异进行合并

git版本2.9.3

我尝试过的事情（不起作用或没有帮助）

确认我从未在本地主分支上提交任何内容，并且这些冲突文件不存在

克隆了另一份回购协议副本，并确认我从未提交过任何内容，并且这些冲突文件不存在

在重新设置基础之前，我做了一个

“git重置--硬头”

，没有任何帮助。 删除了一些未被跟踪的本地.gitignore文件，以尝试隔离分支之间可能发生且不一致的任何行为

我尝试使用合并工具解决这些冲突

我在git丢失这些文件的冲突解决方案时遇到了问题，因为差异的结果是我总是接受正确的本地版本，git认为本地版本没有变化

我尝试了git

rebase--skip

但这似乎对上述情况没有帮助，所以我放弃了

我试图通过合并获得电力，但一小时后就放弃了。我在本地进行了数百次提交

我打开了

reere.enabled

，并再次尝试上述操作。rebase尝试应用

“录制的预映像”

，但失败，要求我像以前一样手动合并非冲突

那些有用的东西 我可以毫无问题地并入我的分支机构。合并是干净的和自动的，正如在这种上下文中所应该的那样。这对我来说效果很好，但我最终不得不后退，不能传播这个问题

其他资料 我将我的分支合并回了主节点，现在我发现对主节点进行git拉取——重新基址现在已经成功了

    git checkout mybranch
    git merge master mybranch (success)
    git checkout master
    git merge mybranch master (success)
    git pull --rebase (conflicts in files that dont exist on remote.)

看起来像： 我的倾向是放弃存储库的本地克隆，并合并到一个带有文件系统的新存储库中 diff然而，我真的很想了解发生了什么，如果可能的话，我想保持提交历史记录，但我不能合并回远程，尽管我认为这会起作用，因为我相信这会有传播这个问题的风险（不管是什么）。

根据您的评论“[…]交互式重新基础中的前20次提交重复[…]”，我相信我能解释这个问题

假设提交如下所示：

A
B
C
A
B
C

当Git执行rebase时，它会尝试按照列出的顺序一次一个地应用每个提交

应用提交

A

-无问题

应用提交

B

-无问题

应用提交

C

-无问题

应用提交

A

-冲突，因为这些更改已经应用

当然，当您手动解决冲突时，不会显示任何内容，因为更改是相同的。这也是为什么

merge

可以毫无问题地工作——它只是比较最新版本

---

那么，如何解决这个问题呢？

git-rebase-i-master

删除重复的提交消息。这很乏味，但只需要一次

git推送-f

---

但这是怎么发生的？

这纯粹是猜测，但这就是我如何陷入类似情况的原因。在某些情况下，这些提交是与以下类似的分支结构的一部分：

master o-o-o-o-o
            \
branch-1     o-A-B-o
                    \
branch-2             o-o

然后通过git rebase master更新分支-1：

master o-o-o-o-o
            \   \
branch-1     \   o-A`-B`-o
              \
branch-2       o-A-B-o-o

然后通过git rebase branch-1更新分支-2：

master o-o-o-o-o
                \
branch-1         o-A`-B`-o
                          \
branch-2                   o-A-B-o-o

因此，提交变得重复

---

下一步是什么？

如果重复的提交消息是从

master

提交的-其他人已重新写入

master

的历史记录。这对于共享回购中的任何人来说都是糟糕的形式，并且（如果可能的话）您应该更改

master

的权限，以禁止任何人强制推送

---

如果重复的提交消息来自

mybranch

，那么我猜您在某个时候有一个子分支，在从master获取最新更改时犯了错误。我使用中描述的过程来处理这种情况（简而言之，在重新设置分支2的基址时，您需要使用

--to

标志）。

如果您查看

mybranch

的

git日志

，历史是否与您期望的一样？具体来说，您是否看到任何重复的提交消息？或者，如果您执行交互式重新基址（

git-rebase-i master

），提交列表是否正确-即是否显示“abc”？关于git日志：据我所知，历史记录是否正确。许多用户提交了数百次，因此很难确定。我对我的用户名做了一些过滤，但没有发现明显的错误。我之前看到的交互式重基似乎也很合理。在我启动一个重设基础后，它会将一些从目标到目标的提交倒回并修补到源分支上，它会开始出现问题。仔细观察后，我发现交互式重设基础中的前20个提交会重复，我不确定这意味着什么，或者如果是，它与问题有什么关系

master o-o-o-o-o
            \   \
branch-1     \   o-A`-B`-o
              \
branch-2       o-A-B-o-o

master o-o-o-o-o
                \
branch-1         o-A`-B`-o
                          \
branch-2                   o-A-B-o-o