我正在以非交互方式将要素分支基于其母版上git rebase feature master。
在此过程中出现了一系列冲突，我一次手动解决了。但是，在冲突＃3中，我忘记保存具有一系列广泛更改的文件，只是盲目地git add该文件，所有冲突和git rebase --continue。
现在，我处于另一个冲突中，由于先前的冲突，文件看起来像是一团糟。 git rebase为我提供了--continue，--skip和--abort，但我不想执行以下任何操作：我想“备份”到先前的提交并保存之前忘记保存的更改在重新设置基准的此步骤“重新应用”补丁。
最简单的方法是什么？
不幸的是，这是Git非常弱的一种情况。
底层系统中的某些东西可以使“回到我之前的步骤”变得容易（嗯，即使使用交互式rebase，将都很容易，如果Git保存了要做的rebase-do每个步骤的说明表，虽然不是，但是很容易做到）。但是，rebase代码中实际上没有实现此目标的任何东西。
如果到目前为止，您在提交中做了很多工作，则可以在分离的HEAD上立即设置分支或标记名称：
git tag temp-save
例如，然后使用git rebase --abort退出entire变基。
否则，请使用git rebase --abort退出entire变基。
然后，从git rebase开始。
当您遇到已经解决的冲突时，可以通过运行以下命令来重用您在先前的，现在已中止的，重新设置基准中所做的任何提交：
git log temp-save
并找到您在上一次运行中所做的提交。使用：
git reset --hard
git read-tree -u <hash>
-或更简单，但我尚未对其进行测试：
git read-tree --reset -u <hash>
-使用从终止的rebase的temp-save输出中找到的哈希值，从git log temp-save找到的先前工作中加载索引和工作树。您可以根据需要进一步修复它，然后单击git rebase --continue。一旦超过了要倒带的位置，就可以删除临时分支或标记：
git tag -d temp-save
而且您在重新定级的第一轮中所做的提交将很难找到。
这是我为解决此问题所做的工作，以供将来参考。这篇文章给出了一些提示：
git rebase --abort。.git/logs/HEAD中查找我搞砸的提交SHA。 （即使中止了变基，也将保存这些内容。）git checkout -b recovery SHA。git commit -m "resolve conflicts"之上。git cherry-pick将其余的基准提交到recovery。完成变基（这次更加小心地保存更改：）。git checkout feature和git reset --hard recovery。如果我在上面执行此过程，则上面会有额外的"resolve conflicts"提交。如果很重要，我可以通过在git rebase -i顶部执行master并将其压入它应该属于的提交中来摆脱它。