在 git 交互式变基期间添加了新文件,变基中止,新文件丢失

发布于 2024-12-10 14:03:02 字数 196 浏览 0 评论 0原文

我之前在几个节点上提交了 git rebase -i 。我添加了一些我打算添加到该提交中的新文件。

看起来我在错误的节点上,所以我立即执行了 git rebase --abort。这些新文件现在完全消失了。在引用日志中,看起来像是发出了删除命令(删除文件模式 100644),但甚至不存在文件名。

这看起来不太好,但我想我会问 - 这可以恢复吗?

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?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

︶ ̄淡然 2024-12-17 14:03:02

不,这些更改不是“可恢复的”,因为它们可以通过单个命令获取。是的,这些更改是在 git fsck 中发现的,还有我必须整理的 100 多个其他旧更改。很糟糕,但总比完全失去要好。

需要注意的重要事项:
- 一旦你执行“git add”,该提交节点就会被记录 - 从那时起事情就不会完全丢失
- “git rebase abort”不像回滚事务,它更像是“git reset --hard”,它将删除在该 rebase 期间添加的任何新文件。 Git 不会跟踪您在变基期间所做的更改,因此它无法“撤消”它们或回滚它们。在 rebase 期间,您处于无人区,中止 rebase 就是 git 重置回之前的提交节点。

重新总结这个问题 - 我做了一些更改,并将它们组织成单独的提交,每个提交 1 个功能。中途,我意识到我错过了早期(未推送)提交中的一些文件。我做了一个 git stash,启动了一个交互式变基,做了一个 git stash pop,将丢失的文件添加到之前的提交中,并意识到我已将新文件添加到了错误的提交节点。然后,我执行了 git rebase --abort,它删除了这些新文件,而且通常很糟糕。

TLDR:在交互式变基期间,请勿在未先备份新文件的情况下添加新文件 - 如果中止变基,您的文件将(大部分)丢失,并且不易恢复。

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.

只涨不跌 2024-12-17 14:03:02

由于这些文件从未添加到 DAG 中,因此看起来无法恢复,除非您在某处有它们的第二个副本。但是,如果您将它们添加到索引中,您将能够通过 @jefromi 建议的 git fsck --lost-found 找到它们。

更多信息:

查看 reflog 将显示您的分支之前指向的位置。您想使用 git log 来查看实际历史记录。添加 --stat 选项以查看每次提交时的文件更改。

Since the files were never added to the DAG, it does not look like it's recoverable unless you have a second copy of them somewhere. If you added them to the index, however, you will be able to find them through, as @jefromi suggests, git fsck --lost-found.

More info:

Looking at reflog will show you where your branch pointed to before. You want to use git log to the the actual history. Add the --stat option to see the file changes at each commit.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文