git：恢复新分支的未分配更改

发布于 2025-02-12 12:10:24 字数 424 浏览 1 评论 0 原文

如果我有一个本地git仓库，其中 branch1 中的未分段更改，则进行以下操作：

结帐到新分支： branch2
提交一些（不是全部）文件
运行 git重置 - hard 来自 branch2
结帐回到 branch1

我如何做到这一点而不会失去 branch1 的变化？我是否必须从 branch1 或 branch2 中运行 git stash ，还是首先提交这些文件？还是在使用git之前我仍然可以恢复我的未承诺的更改？

原文

分享到QQ

分享到微博

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

发布评论

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

源来凯始玺欢你 2025-02-19 12:10:24

您可以将运行 git Reset Reset 时忽略 - 硬，因为这是恢复未分段的更改的原因。如果由于某种原因不可行，则必须使用 git Stash 。

回复收藏 0 原文

真心难拥有 2025-02-19 12:10:24

您在这里犯的基本错误是，“变更”（分阶段或未分级）是“分支机构”。他们不是！无论我们使用哪种含义，这都是Git具有的 branch 一词的许多含义。实际上，从非常重要的意义上讲，如存储库完全。

太多的GIT介绍性教程首先要暗示，甚至直接声称Git是关于文件和分支的。不是：实际上是关于 consits 的。 consits 是存储库中或大部分内容的内容。一旦犯下了某事，它将被安全保存永远保存 - 始终，几乎永远，几乎几乎< /em>安全（例如，您可以始终完全破坏存储库）。因此，我们应该首先专注于提交。

不幸的是，提交自己似乎都是抽象和模糊的。如果您要求git向您展示一个提交 - 例如，例如， git show - 您获得了这种输出：

$ git show
commit e4a4b31577c7419497ac30cebe30d755b97752c5 (tag: v2.37.0, ...)
Author: Junio C Hamano <[email protected]>
Date:   Mon Jun 27 09:17:55 2022 -0700

    Git 2.37
    
    Signed-off-by: Junio C Hamano <[email protected]>

diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index 120af376c1..b210b306b7 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -1,7 +1,7 @@
 #!/bin/sh
 
 GVF=GIT-VERSION-FILE
-DEF_VER=v2.37.0-rc2
+DEF_VER=v2.37.0
 
 LF='
 '

这是一个提交吗？好吧，这是的代表，正如下图是女人的代表一样。这实际上不是女人，而是一幅画。但这实际上也不是一幅画：这是一幅的JPG 。请注意，我们甚至可以就真正的东西是达成共识之前，我们可能必须如何走动。这是我们遇到的问题之一，定义 commit 是什么。

https://upload.wikimedia.org/wikipedia/commons/commons/commons/thumb/e/e0/mona_lisa-lisa-risa-rz.jpg/507px-mona_lisa_lisa-lisa-risa-rz.jpg”

E4A4B31577C7419497AC30CEBE30D755B97752C5 上面。 我们 can 长时间使用git 而没有更多的了解，但是我们不应该。

您需要知道的绝对最小值不幸的是，使用git

是至少最终需要知道的 lot 。 git很棘手！有很多关于它的知识。但是，最低限度要知道，这样您就不会遇到麻烦，而且会像这样：

a 存储库 stores Consits 。这不一定是全部存储的，但这是主要的事情。
a commit 是存储 files和metadata 的编号（通过哈希ID）。
每个提交都存储每个文件的完整快照，以及该元数据。快照只是一个快照 - 元数据记得“关于此提交的东西”，例如制造它的人的名称和电子邮件地址。
每个提交的所有部分一直都在冻结。在中，没有什么可以改变提交！如果提交很糟糕，我们可以通过制作我们使用的新版本来停止使用。但这不会使旧的提交停止现有。再说一次，就像在旧的谜语中一样，如果一棵树落在森林里，没有人听到它，它是否会产生“噪音”（“噪音”的意思是“冒犯了所有听到的人”）？如果您找不到一个提交，是否存在？
git 发现那些丑陋的哈希ID的承诺。人类对这些不好，因此Git也为我们提供了分支名称的东西。我们使用的名称（分支名称，标签名称和所有其他类型的名称）为我们存储Hash ID。每个名称实际上只是存储一个 hash ID，但这已经足够了。
因为提交快照都被冻结了（委托中的文件也被神奇地删除了 - 很快就变得很重要，但是您没有立即知道它），您实际上是< em>无法在订入的文件上使用。所以你不会。 的行为 使用 git Checkout 或 git switch ，将Git告诉提取保存的文件 。这些成为您可以使用和使用/使用的普通文件。
这些普通文件不在存储库中！（嗯，在某种程度上，这完全取决于我们如何定义 repository ，而是要使此列表简短，请不要参与其中。
最后，git make new 从其用几个名称调用的东西中提出了：这些天 - 缓存。这个事情的存在是为什么git让您如此运行 git add 太多了，它解释了许多其他git怪异。

当您刚开始时，您可能会在此索引 /登台区域中保持模糊性。请记住，它的存在很重要 - 它持有您的提议下一个提交 - 并尽快进一步了解它。

一旦您真正了解了这八件最低限度的事情，就可以在git中完成一些工作。您可以将其引用到其手动页面，其中有些甚至可以启动有点意义。

The fundamental error you're making here is thinking that "changes" (staged or unstaged) are "in a branch". They're not! This is true no matter which meaning we use, of the many meanings of the word branch that Git has. In fact, in a very important sense, as tkausl commented, the work you're doing, as you're doing work, isn't really in the repository at all.

Too many Git introductory tutorials begin by implying, or maybe even outright claiming, that Git is about files and branches. It isn't: it's really all about commits. The commits are what go in the repository, or most of what goes in. Once something is committed, it's safely preserved forever—well, almost forever and almost safe (you can always completely destroy the repository entirely for instance). So we should focus first on the commits.

Unfortunately, commits themselves seem all abstract and vague. If you ask Git to show you a commit—using, e.g., git show—you get this sort of output:

$ git show
commit e4a4b31577c7419497ac30cebe30d755b97752c5 (tag: v2.37.0, ...)
Author: Junio C Hamano <[email protected]>
Date:   Mon Jun 27 09:17:55 2022 -0700

    Git 2.37
    
    Signed-off-by: Junio C Hamano <[email protected]>

diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index 120af376c1..b210b306b7 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -1,7 +1,7 @@
 #!/bin/sh
 
 GVF=GIT-VERSION-FILE
-DEF_VER=v2.37.0-rc2
+DEF_VER=v2.37.0
 
 LF='
 '

Is that a commit? Well, it's a representation of a commit, just as the image below is a representation of a woman. It's not actually the woman, it's a painting. But it's not actually a painting either: it's a JPG of a painting. Note how we may have to go around and around before we can even agree on what something really is. That's one of the problems we have, defining what a commit is.

Still, once we've used Git for a bit, we have at least a pretty good vague idea of what a commit is: it's a numbered (by hash ID) entity, like commit e4a4b31577c7419497ac30cebe30d755b97752c5 above. We can use Git for a long time without knowing much more than this, but we shouldn't.

The absolute minimum you need to know when using Git

There is, unfortunately, a lot that we need to know, at least eventually. Git is tricky! There's a lot to learn about it. But there's a bare minimum to know so that you won't get into trouble, and it goes like this:

A repository stores commits. That's not necessarily all it stores, but that's the main thing.
A commit is a numbered (by hash ID) thingy that stores files and metadata.
Each commit stores a full snapshot of every file, plus that metadata. The snapshot is just that—a snapshot—and the metadata remembers "stuff about this commit itself", such as the name and email address of the person who made it.
All parts of every commit are frozen for all time. Nothing in a commit can ever be changed! If a commit is terrible, we can stop using it, by making a new and improved version that we use instead. But that won't make the old commit stop existing. Then again, as in the old riddle, if a tree falls in the forest and there's no one around to hear it, does it make a "noise" (where "noise" means "offends all the people who heard it")? If you can't find a commit, does it matter if it exists?
Git finds commits by those big ugly hash IDs. Humans are bad at those, so Git gives us things like branch names too. The names we use—branch names, tag names, and all other kinds of names—store the hash IDs for us. Each name actually stores just one hash ID, but that's good enough.
Because commit snapshots are all frozen (the files in the commits are magically de-duplicated too—that becomes important soon, but you don't have to know it right away), you literally can't work on the committed files. So you don't. The act of checking out a commit, with git checkout or git switch, tells Git to extract the saved files. These become ordinary files that you can use and work on / with.
These ordinary files are not in the repository! (Well, to some extent this depends on exactly how we define repository, but to keep this list short, let's not get into this.) They are, instead, in your working tree or work-tree.
Last, Git makes new commits from a thing it calls by several names: the index, or the staging area, or—rarely these days—the cache. The existence of this thing is why Git makes you run git add so much, and it explains a whole lot of other Git weirdness.

When you're just getting started, you can remain kind of fuzzy on this index / staging-area thing. Just remember that it exists and it's important—it holds your proposed next commit—and get around to learning more about it soon.

Once you really know these eight minimum things, you can get some work done in Git. You can refer back to its manual pages and some of them might even start to make a little bit of sense. ????

The git reset command is, unfortunately, a very large and complicated command that does a lot of things. But you'll see that—as SebDieBin answered—--hard erases working tree files, replacing them with files that come out of some commit. Since you've memorized the above points by now—well, maybe you have—you will know that the working tree files aren't actually in the repository. They may have come out of some commit, but if you've changed them since then, the updated files are only there in the working tree. Erasing those files—removing them and replacing them with committed versions instead—therefore erases your changes, and since those changes were never in Git, Git can't help you get them back.

You can take this to mean git reset --hard is scary, be careful with it, which is good advice. But this doesn't really go far enough: there are a lot of other Git operations that can remove, forever, Git's ability to help you get back unsaved changes. What you really need to know is what makes you safer. Once you've committed something—made a full snapshot of every file from Git's index or staging-area—the committed files are safely stored for as long as you can find that commit's hash ID. Well, and, as long as your laptop doesn't catch fire, for instance.

Laptopt on fire