问题描述
我在之前的几个节点上做了一个git rebase -i。我添加了一些新的文件，我打算添加到该提交中。看起来我是在错误的节点上，所以我立即做了一个git rebase --abort。那些新文件现在完全消失了。在reflog中，它看起来像是发出了一个删除命令（删除文件模式100644），但是甚至没有文件名。
这看起来不太好，但我想我会问 - 这是可以恢复吗？
不，这些更改不是可恢复的，因为他们可以被一个命令抓住。是的，这些更改是在git fsck中发现的，还有其他100多个我必须排序的旧更改。 Ick，但胜过完全损失。
重要的注意事项：
- 只要您执行了git add，就会记录该提交节点 - 事情不能从这一点完全丢失
- git rebase abort不像是回滚一个事务，它更像是一个git reset --hard，它会删除任何在重新绑定期间添加的新文件。 Git不会跟踪您在重新绑定期间做了哪些更改，因此它不能撤消它们或将它们还原。重新绑定期间，您将进入无人区域，并且放弃重新绑定是将git重置回到先前的提交节点。
重新总结问题 - 我做了一些改变，并将它们组织成不同的提交，每次提交一个功能。过了一半，我意识到我错过了一些早期（未完成）提交的文件。我做了一个git存储，开始了一个交互式rebase，做了一个git stash pop，将错过的文件添加到了之前的提交中，并且意识到我已经将新文件添加到了错误的提交节点。然后，我做了一个git rebase --abort，它删除了这些新文件，并且通常很糟糕。
TLDR：不要在没有第一个交互式重新绑定的情况下添加新文件支持他们 - 如果您中止rebase，您的文件将（主要）丢失，并且不容易恢复。
I did a git rebase -i on a commit several nodes earlier. I added some new files I meant to add to that commit.
It looked like I was on the wrong node, so I immediately did a git rebase --abort. Those new files are now entirely gone. In the reflogs, it looks like a delete command was issued (deleted file mode 100644), but not even the file name is present.
This doesn't look good, but I figured I'd ask - is this recoverable?
No, the changes were not "recoverable" in that they could be grabbed by a single command. Yes, the changes were found in a git fsck, along with 100+ other old changes that I had to sort through. Ick, but better than full loss.
Important things to note: - As soon as you do a "git add", that commit node is recorded - things cannot be entirely lost from that point - A "git rebase abort" is not like rolling back a transaction, it is more like a "git reset --hard" that will delete any new files that were added during that rebase. Git does not track what changes you did during your rebase, so it cannot "undo" them or roll them back. During the rebase, you're in a no-man's-land, and aborting the rebase is a git reset back to a previous commit node.
To re-summarize the problem - I made a handful of changes, and was organizing them into separate commits, 1 feature per commit. Halfway through, I realized I had missed some files on an earlier (unpushed) commit. I did a git stash, started an interactive rebase, did a git stash pop, added the missed files to a previous commit, and realized I had added the new files to the wrong commit node. Then, I did a git rebase --abort, which deleted those new files, and was generally horrible.
TLDR: Do not add new files during an interactive rebase without first backing them up - if you abort the rebase, your files will be (mostly) lost, and not easily recoverable.
这篇关于在git交互式rebase中添加新文件，中止rebase，新文件丢失的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！