Git Rebase期间的Git Commit - 到底发生了什么？

Question

我正在寻找一个关于rebase时提交所发生的情况以及如何用简单的方法“撤销”的好描述。

让我们考虑这样一种情况，一个大型提交正在被rebase。在rebase期间出现了冲突，用户开始合并更改。 现在，想象一下这样一种情况，你已经快做完了，但是由于某种原因（比如长周末等），你没有调用git rebase --continue。接下来的一周你继续工作，仍然处于rebase状态。最后，你调用git commit --amend将更改附加到上一个提交中，并且……它们出现在你正在rebase的提交中。

当然，你总是可以检出你开始rebase的提交并“hack your way through”——例如尝试从你的修改中复制所有文件，但是这可能会丢失在此期间引入的变更。

有没有清晰而好的方法来解决这个问题？这是一个特定的状态，我应该小心避免，但是偶尔还是会发生-我最终花费了整整一天时间来搞清楚事情。

我真的很感谢所有的帮助和建议。谢谢！

- Tomasz W

---

我不确定这种方法是否在所有情况下都有效，但你是否尝试过将你的最终结果（包括修改基础提交）重新设置到原始基础提交上呢？我曾经模拟了相同的情况并且成功了。这另一个重新设置引入了新的冲突，但如果你解决了它并执行git rebase --continue，那么你最终会得到两个提交：原始基础提交和重新设置后的更改。它们都有相同的提交信息（就像原始基础提交一样），但可以很容易地使用git --amend修复此问题。 - KL-7

我会看一下，听起来很合理。谢谢！ - Tomasz W

使用git_ps1将存储库状态放入你的提示符中。你会始终注意到你有一个未完成的变基。 - camh

很遗憾，它对我来说并没有完全起作用。 事实证明，这与撤销提交并再次进行rebase并没有太大区别；更好的是，一旦不幸的提交完成rebase后，最好切换到rebase head，启动新分支，并使用--no-commit --no-ff --strategy=theirs合并更改（在gerrit的情况下）并复制changeid。 - Tomasz W

这对我很有用。虽然不是“快乐路径”，但很容易理解正在发生的事情：1）将整个工作区复制到版本控制之外的某个文件夹中。2）中止变基并删除本地分支。3）从远程分支获取和拉取。4）重新开始变基。对于任何冲突，从步骤1中复制文件的版本。 - Max Heiber

Answer 1

针对这种情况，有两个提出的解决方案。

• 第一个解决方案是将最终结果变基回原始基础提交。这将要求您再次解决类似的合并冲突，但完成后您的提交应该会回到正轨。

• 另一个解决方案，适用于我自己的情况，是从您修改的提交相同点创建分支（它包含 SHA，应用作检出基础）。然后创建一个新分支并调用 git merge --no-ff --no-commit --strategy=theirs other_branch，其中*other_branch*是带有不幸提交的那个分支。

- Tomasz W