git rebase --continue无法工作。

Question

我执行了 git rebase master，解决了一个文件中报告的冲突，然后使用 git add 命令将该文件添加到已解决的冲突中。然后我执行 git rebase --continue 命令，结果得到以下提示：

应用: 修复单元测试

没有变更 - 你是否忘记使用 'git add' 呢？如果没有需要暂存的内容，有可能是其他人已经引入了相同的变化；你可以跳过此补丁。

当你解决了这个问题之后，运行 "git rebase --continue"。如果你想要跳过此补丁，请运行 "git rebase --skip"。如果你想要回到原始分支并停止 rebase，请运行 "git rebase --abort"。

你有什么想法吗？我在这里漏掉了什么吗？应该执行 git rebase --skip 吗？

- Boon

---

git diff 显示哪些内容有所不同。如果它没有显示任何差异，那么你的 rebase 已经产生了一个空提交，可以安全地跳过它。 - cmbuckley

git diff 没有显示任何内容。 - Boon

如下所述，几乎可以确定是提到的错误。如果你使用 --skip 命令，你将会失去最后一次提交，当然你可以挖掘出它包含的任何更改，并在重新基于分支时重新实现它们。另一种选择是使用 --abort 命令，放弃当前的变更并重新开始。 :-( - T. Benjamin Larsen

更改配置文件？嗯？ - Cheeso

对于我来说，“git rebase --skip”，“git add .”，然后再次运行“git rebase --continue” - onmyway133

Answer 1

如果你使用的是Mac OS X，首先应该禁用revisiond。因为在 rebase 过程中，它可能会干扰你工作树中的文件，导致不可预测和破损的行为:

git config --global core.trustctime false

这个问题在这篇文章中有解释，非常感谢@nickfalk指出。

至于你的变基操作，在实践中这种情况并不少见。让我们尝试思考一下正在发生的步骤：

• 当你将当前分支变基到另一个分支上时，Git会将HEAD移动到另一个分支，并开始应用你当前分支中的唯一提交。

• 在重放其中一个提交时，你遇到了冲突。你解决了它，但结果是没有任何更改被提交，没有任何东西需要在此提交中重放。

实际上，这意味着你拒绝了正在重放的当前提交中的更改。因此，如果你不需要这个提交中的任何内容，跳过它是很正常的。所以在这里使用git rebase --skip是有意义的。

- janos

---

如果有关的提交被忽略，且其更改未被接受作为解决冲突的一部分，那么这确实是有意义的。然而，考虑到下面提到的众所周知的错误，这也很容易意味着您会失去该提交中预期的更改... - T. Benjamin Larsen

你说得对，我现在已经添加了这个信息，感谢你指出！ - janos

这让我很疯狂。非常感谢你。我还想注意到你很棒。 - CommaToast

Answer 2

我在我的项目中遇到了类似的问题，通过将 --preserve-merges 选项添加到rebase命令中解决了该问题。在我的项目中，这个问题是由一个合并提交引起的，这是一个“空提交”。使用 git rebase --preserve-merges 命令，它会保留合并提交并继续合并而不会破坏提交树。

- Eliseu Egewarth

---

这拯救了我的一天。我正在使用Ubuntu，因此其他答案对我不适用，但你的适用。添加 --preserve-merges 选项最终完美地运行了，因为git向我展示了我树中的进一步问题，但这些问题可以手动修复。 - Alejandro de Haro

感谢您发布这篇文章，真是帮了我大忙！ - Draqun

这对我在Ubuntu上起了作用。 - nbeuchat

我收到了一个弃用警告，建议使用 git rebase --rebase-merges。这个命令非常好用！ - John Crawford

@JohnCrawford git rebase --rebase-merges 是官方 git 文档 git-scm 推荐的新命令选项。 - undefined

Answer 3

放松，你不要发疯！;-= 这是一个已知的问题，如果你使用的是OSX系统，它会影响git；详细情况请参考Tower（而不是我）。

简单来说（即解决方法）是：

git config --global core.trustctime false

- T. Benjamin Larsen

---

我以前在处理大型rebase时经常遇到这个问题。感谢您指出！ - Josh Kovach

是的，OSX。这个修复方法行不通 :( - Boon

很可能这不会对您当前的变基有所帮助。它已经在文件系统中基于现有信息进行了基础。不确定，但如果您重新启动变基，它可能会起作用... - T. Benjamin Larsen

@nickfalk，感谢您回答这个问题。我选择了另一个答案，因为它对我有帮助，但是您的答案也可以帮助其他人。 - Boon

不用担心，Boon。希望你百分之百确定决定忽略你所提到的提交所做的任何更改是你想要的... - T. Benjamin Larsen

Answer 4

我尝试了所有的方法，但都没有奏效。如果您没有处于rebase过程中，但git一直在抱怨，请尝试以下方法。这对我在OSX上起作用了。

rm -fr ".git/rebase-apply"

- Vino

Answer 5

git add .会使你从这种状态中解脱出来，但如果你通过接受传入的更改来解决了所有冲突，则没有差异可添加，因此git认为在rebase方面冲突未得到解决。

我采取了一种低端方法，它可以在不依赖于使用神秘的git配置更改等副作用的情况下工作：

• 向每个冲突文件添加无害内容（例如一行上的//），以便让git有些东西可以add
• git add .
• git rebase --continue
• 删除无害注释

所有问题都解决了

- Bohemian

Answer 6

以上的建议都没有起作用。我发现这个问题是因为我对主分支进行了硬重置，而我的特性分支有一些旧的主分支提交记录（不要问我怎么回事 - 我也不知道 :( ）。

我将我的更改复制到一个临时目录中，删除了我的特性分支，将它们复制回来，并从头开始重新启动。丑陋但有效。如果您想在特性分支中保留多个提交，则不建议使用此方法。除非您已经尝试了所有其他方法，否则不建议使用此方法。

更新：这种方法虽然可行，但下面的评论中指出了更好的方法。请看一下。

- Gi0rgi0s

---

如果从单个提交（甚至只有几个）获取更改，则将它们放在单独的临时本地分支上要好得多，然后检出您的工作分支，将其重置为更改之前，必要时进行变基，然后挑选。这就是 cherry-pick 的作用 - 不需要手动复制东西。 - Adas Lesniak

@AdasLesniak 那是一个非常好的观点！我希望去年在解决我的问题时能想到这一点。 - Gi0rgi0s

Answer 7

这很可能意味着更改已经被合并了。只需检查git状态即可。

- Neo

---

已检查状态，不是。 - Boon

如果我仍在rebase的过程中并且还没有完成，那么这些更改怎么可能已经被“rebase”了呢？ - Szczepan Hołyszewski