我之前在几个节点的提交上做了一个 git rebase -i 。我添加了一些我打算添加到该提交的新文件。
看起来我在错误的节点上，所以我立即执行了 git rebase --abort。这些新文件现在完全消失了。在 reflogs 中，似乎发出了删除命令（已删除文件模式 100644），但甚至文件名都不存在。
这看起来不太好，但我想我会问 - 这可以恢复吗？
【问题讨论】：
标签： git
不，更改不是“可恢复的”，因为它们可以通过单个命令获取。是的，这些更改是在 git fsck 中找到的，以及我必须整理的 100 多个其他旧更改。糟糕，但总比完全失去要好。
需要注意的重要事项： - 一旦您执行“git add”，该提交节点就会被记录 - 从那一刻起，事情不会完全丢失 - “git rebase abort”不像回滚事务，它更像是“git reset --hard”，它将删除在该 rebase 期间添加的任何新文件。 Git 不会跟踪您在变基期间所做的更改，因此它无法“撤消”它们或回滚它们。在变基期间，您处于无人区，中止变基是 git 重置回之前的提交节点。
重新总结问题 - 我做了一些更改，并将它们组织成单独的提交，每个提交 1 个功能。进行到一半时，我意识到我在之前的（未推送的）提交中遗漏了一些文件。我做了一个 git stash，启动了一个交互式 rebase，做了一个 git stash pop，将丢失的文件添加到以前的提交中，并意识到我已经将新文件添加到了错误的提交节点。然后，我做了一个 git rebase --abort，它删除了那些新文件，而且通常很糟糕。
TLDR：不要在没有备份的情况下在交互式 rebase 期间添加新文件 - 如果您中止 rebase，您的文件将（大部分）丢失，并且不容易恢复。
【讨论】：
由于这些文件从未添加到 DAG，因此除非您在某处有它们的第二个副本，否则它看起来是不可恢复的。但是，如果您将它们添加到索引中，您将能够通过@jefromi 建议的git fsck --lost-found 找到它们。
更多信息：
查看 reflog 将显示您的分支之前指向的位置。您想将git log 用于实际历史记录。添加--stat 选项以查看每次提交时的文件更改。
【讨论】：
git add -A 将所有更改（包括删除）添加到索引。一旦您git rebase --continue，更改将被考虑在内。如果您仍在交互式 rebase 中，git rebase --abort 会丢弃您在任何步骤中所做的任何事情。
rebase --abort 删除，那么它们可能在索引中。 rebase 不会触及完全未跟踪的文件。并且索引对象不是写入对象目录吗？ @chaqke：git fsck 找到什么有用的东西了吗？您可以使用git fsck --lost-found 将悬空对象写入.git/lost-found。