【发布时间】：2012-06-22 09:55:25
【问题描述】：
我正在寻找一个很好的描述，如果一个人在变基期间提交会发生什么，以及如何以一种简单的方式“恢复”。
让我们考虑一个场景，其中大型提交被重新设置。在 rebase 期间会出现冲突，并且用户开始合并更改。 现在，想象一下您几乎完成的场景，但您没有调用 git rebase --continue - 无论出于何种原因（无论是长周末还是这样）。下周你刚刚恢复工作，仍然在 rebase 期间。最后，您调用 git commit --amend 将更改附加到最后一次提交，然后......它们最终会出现在您要重新定位的提交中。
当然，您总是可以检查您开始变基的提交并“破解您的方式” - 例如，尝试从您的修改中复制所有文件，但这可能会放弃在同时。
有没有一个干净的好方法来解决这个问题？这是我应该小心的一种特殊状态，我不想最终陷入这种状态，但它仍然偶尔会发生 - 我最终会花一整天的时间试图把事情弄清楚。
非常感谢所有帮助和建议。谢谢！
【问题讨论】：
-
不确定它是否适用于每种情况，但您是否尝试过将最终结果（修改了基本提交）重新定位到原始基本提交上？我试图模拟相同的情况并且它奏效了。这另一个 rebase 引入了一个新的冲突，但如果你解决它并执行
git rebase --continue，那么你最终会得到两个提交：原始基础和你的 rebase 更改。它们都具有相同的提交消息（与原始基本提交一样），但使用git --amend很容易修复。 -
我去看看，听起来很正常。谢谢！
-
使用 git_ps1 将存储库状态放入提示符中。你总是会注意到你有一个未完成的变基。
-
恐怕它对我来说不太有效。事实证明，这与恢复提交并再次进行 rebase 并没有什么不同；更好的是，一旦 rebase 通过不幸的提交完成，最好切换到 rebase 头，开始新分支并使用 --no-commit --no-ff --strategy=theirs 和合并更改（如果gerrit) 复制 changeid。
-
这对我有用。不是“快乐的道路”，而是很容易理解发生了什么：1）将整个工作区复制到版本控制之外的某个文件夹。 2）中止变基并删除本地分支。 3) 从远程分支获取和拉取 4) 重新启动 rebase。对于任何冲突，请复制步骤 1 中的文件版本。
标签： git commit rebase git-rebase git-commit