如何恢复隐藏的未提交的更改 [英] How to recover stashed uncommitted changes

问题描述

我在开发部门进行了一些未提交的更改，并使用git stash将其隐藏起来，但是其中一些更改在那些隐藏的更改中非常重要.有什么办法找回这些更改吗?

I had some uncommitted changes in my development branch and I stashed them using git stash, but there were some changes which were very important among those stashed ones. Is there any way to get back those changes?

此外，此后，我还在隐藏的代码文件上进行了一些更改.

Also, I have made some changes on top of the stashed code files since.

如果可能的话，我是否有可能将隐藏的更改检索到新分支?

Is there any chance I can retrieve the stashed changes to a new branch if possible?

推荐答案

简单问题的简单答案是git stash apply

只需签出要进行更改的分支，然后再按git stash apply.然后使用git diff查看结果.

The easy answer to the easy question is git stash apply

Just check out the branch you want your changes on, and then git stash apply. Then use git diff to see the result.

在完成所有更改后-apply看起来不错，并且您确定不再需要隐藏的内容-然后使用git stash drop摆脱它.

After you're all done with your changes—the apply looks good and you're sure you don't need the stash any more—then use git stash drop to get rid of it.

我总是建议使用git stash apply而不是git stash pop.区别在于apply将存储区保留下来以便于重试apply或查看等.如果pop能够提取存储区，它也会立即也drop对其存储，并且如果您突然意识到想要将其提取到其他位置(在不同的分支中)，或者使用--index或类似方法提取，那并不是那么容易.如果您apply，您可以选择何时drop.

I always suggest using git stash apply rather than git stash pop. The difference is that apply leaves the stash around for easy re-try of the apply, or for looking at, etc. If pop is able to extract the stash, it will immediately also drop it, and if you the suddenly realize that you wanted to extract it somewhere else (in a different branch), or with --index, or some such, that's not so easy. If you apply, you get to choose when to drop.

尽管这是一种或另一种方式，但都相当次要，对于git的新手来说，它应该大致相同. (您可以跳过所有其他步骤！)

It's all pretty minor one way or the other though, and for a newbie to git, it should be about the same. (And you can skip all the rest of this!)

至少有3或4种不同的使用git stash的方式".上面是针对方法1"的简单方法":

There are at least three or four different "ways to use git stash", as it were. The above is for "way 1", the "easy way":

1. 您从一个干净的分支开始，正在进行一些更改，然后意识到您在错误的分支中进行了更改.您只想进行现在的更改，然后将其移动"到另一个分支.

1. You started with a clean branch, were working on some changes, and then realized you were doing them in the wrong branch. You just want to take the changes you have now and "move" them to another branch.

这是简单的情况，如上所述.运行git stash save(或普通git stash，相同的内容).签出另一个分支并使用git stash apply.使用git相当强大的合并机制，这可以使git合并到您之前的更改中. 仔细检查结果(使用git diff)以查看是否喜欢它们，如果喜欢，请使用git stash drop放下藏匿处.完成了！

This is the easy case, described above. Run git stash save (or plain git stash, same thing). Check out the other branch and use git stash apply. This gets git to merge in your earlier changes, using git's rather powerful merge mechanism. Inspect the results carefully (with git diff) to see if you like them, and if you do, use git stash drop to drop the stash. You're done!

您开始了一些更改并将其隐藏.然后，您切换到另一个分支并开始更多更改，而忘记了已藏匿的分支.

You started some changes and stashed them. Then you switched to another branch and started more changes, forgetting that you had the stashed ones.

现在您要保留甚至移动这些这些更改，并且也应用您的存储.

Now you want to keep, or even move, these changes, and apply your stash too.

实际上，您可以再次git stash save，因为git stash进行了一系列更改".如果这样做，则有两个存储区，一个存储区仅称为stash-但您也可以编写stash@{0}-和一个拼写为stash@{1}.随时使用git stash list查看所有内容.最新的始终是编号最小的. git stash drop时，它会丢弃最新的内容，而stash@{1}的内容将移至堆栈的顶部.如果您还有更多内容，则以前是stash@{2}的那个会变成stash@{1}，依此类推.

You can in fact git stash save again, as git stash makes a "stack" of changes. If you do that you have two stashes, one just called stash—but you can also write stash@{0}—and one spelled stash@{1}. Use git stash list (at any time) to see them all. The newest is always the lowest-numbered. When you git stash drop, it drops the newest, and the one that was stash@{1} moves to the top of the stack. If you had even more, the one that was stash@{2} becomes stash@{1}, and so on.

您也可以先apply然后drop一个特定的存储区:git stash apply stash@{2}，依此类推.删除特定的存储区，仅对编号较高的存储区重新编号.同样，没有数字的也是stash@{0}.

You can apply and then drop a specific stash, too: git stash apply stash@{2}, and so on. Dropping a specific stash, renumbers only the higher-numbered ones. Again, the one without a number is also stash@{0}.

如果您堆积了很多储藏物，它可能会变得很杂乱(是我想要的储藏物stash@{7}还是stash@{4}?等等，我只是推了另一个，现在它们是8和5?).我个人更喜欢将这些更改转移到新分支，因为分支具有名称，并且cleanup-attempt-in-December对我来说比stash@{12}有意义得多. (git stash命令采用了可选的保存消息，这些消息可以提供帮助，但是以某种方式，我的所有存储都被命名为WIP on branch.)

If you pile up a lot of stashes, it can get fairly messy (was the stash I wanted stash@{7} or was it stash@{4}? Wait, I just pushed another, now they're 8 and 5?). I personally prefer to transfer these changes to a new branch, because branches have names, and cleanup-attempt-in-December means a lot more to me than stash@{12}. (The git stash command takes an optional save-message, and those can help, but somehow, all my stashes just wind up named WIP on branch.)

(高级)，您已经使用git stash save -p，或者在运行git stash save之前仔细地git add -ed和/或git rm -ed代码的特定位.在隐藏的索引/暂存区中有一个版本，在工作树中有另一个(不同的)版本.您要保留所有这些.因此，现在您使用git stash apply --index，有时会失败:

(Extra-advanced) You've used git stash save -p, or carefully git add-ed and/or git rm-ed specific bits of your code before running git stash save. You had one version in the stashed index/staging area, and another (different) version in the working tree. You want to preserve all this. So now you use git stash apply --index, and that sometimes fails with:

Conflicts in index.  Try without --index.

您正在使用git stash save --keep-index来测试将提交的内容".这个问题超出了答案的范围.请参见其他StackOverflow答案.

You're using git stash save --keep-index in order to test "what will be committed". This one is beyond the scope of this answer; see this other StackOverflow answer instead.

对于复杂的情况，建议您首先提交一个干净的"工作目录，方法是提交您现在所做的任何更改(如果需要，可以在新分支上).这样，您正在应用它们的某处"就没有其他任何东西了，而您只是在尝试隐藏的更改:

For complicated cases, I recommend starting in a "clean" working directory first, by committing any changes you have now (on a new branch if you like). That way the "somewhere" that you are applying them, has nothing else in it, and you'll just be trying the stashed changes:

git status               # see if there's anything you need to commit
                         # uh oh, there is - let's put it on a new temp branch
git checkout -b temp     # create new temp branch to save stuff
git add ...              # add (and/or remove) stuff as needed
git commit               # save first set of changes

现在，您处于一个干净"的起点.也许它更像这样:

Now you're on a "clean" starting point. Or maybe it goes more like this:

git status               # see if there's anything you need to commit
                         # status says "nothing to commit"
git checkout -b temp     # optional: create new branch for "apply"
git stash apply          # apply stashed changes; see below about --index

要记住的主要事情是，隐藏" 是提交，它只是一个稍微有趣/怪异"的提交，而不是在分支上". apply操作查看提交更改的内容，并尝试在您现在的任何位置重复执行.存放处仍会存在(apply保持存在)，因此您可以对其进行更多查看，或确定这是错误的位置，以apply存放，然后以其他方式再次尝试，或执行其他操作.

The main thing to remember is that the "stash" is a commit, it's just a slightly "funny/weird" commit that's not "on a branch". The apply operation looks at what the commit changed, and tries to repeat it wherever you are now. The stash will still be there (apply keeps it around), so you can look at it more, or decide this was the wrong place to apply it and try again differently, or whatever.

每当您有一个储藏室时，就可以使用git stash show -p来查看储藏室中内容的简化版本. (此简化版本仅查看最终工作树"的更改，不是，而--index分别恢复的已保存索引更改.)git stash apply命令(不带--index)只是尝试执行那些相同现在已在您的工作目录中更改.

Any time you have a stash, you can use git stash show -p to see a simplified version of what's in the stash. (This simplified version looks only at the "final work tree" changes, not the saved index changes that --index restores separately.) The command git stash apply, without --index, just tries to make those same changes in your work-directory now.

这是对的，即使您已经进行了一些更改. apply命令很乐意将存储空间应用于修改过的 工作目录(或至少尝试将其应用).例如，您可以执行以下操作:

This is true even if you already have some changes. The apply command is happy to apply a stash to a modified working directory (or at least, to try to apply it). You can, for instance, do this:

git stash apply stash      # apply top of stash stack
git stash apply stash@{1}  # and mix in next stash stack entry too

您可以在此处选择应用"顺序，挑选出特定的存储区以特定的顺序进行应用.但是请注意，每次您基本上都在进行"git merge"，并且如合并文档所警告:

You can choose the "apply" order here, picking out particular stashes to apply in a particular sequence. Note, however, that each time you're basically doing a "git merge", and as the merge documentation warns:

运行git与非平凡的，未提交的更改合并是 灰心:虽然可能，但可能会使您处于困难的状态 在发生冲突的情况下退出.

Running git merge with non-trivial uncommitted changes is discouraged: while possible, it may leave you in a state that is hard to back out of in the case of a conflict.

如果您从一个干净的目录开始，并且仅执行几次git apply操作，则很容易撤消:使用git reset --hard返回到干净状态，并更改您的操作. (因此，对于这些复杂的情况，我建议首先从一个干净的工作目录开始.)

If you start with a clean directory and are just doing several git apply operations, it's easy to back out: use git reset --hard to get back to the clean state, and change your apply operations. (That's why I recommend starting in a clean working directory first, for these complicated cases.)

假设您正在做很多高级Git Stuff，并且已经制作了一个存储，并且想要git stash apply --index，但是由于分支已经分叉，因此不再可以将--index应用于已保存的存储.自您保存以来，太多了.

Let's say you're doing Lots Of Advanced Git Stuff, and you've made a stash, and want to git stash apply --index, but it's no longer possible to apply the saved stash with --index, because the branch has diverged too much since the time you saved it.

这是git stash branch的作用.

如果您:

1. 检查执行原始stash时执行的确切提交，然后
2. 创建一个新分支，最后
3. git stash apply --index

1. check out the exact commit you were on when you did the original stash, then
2. create a new branch, and finally
3. git stash apply --index

尝试重新创建更改肯定会成功.这就是git stash branch newbranch所做的. (然后，由于成功应用了存储，它会删除该存储.)

the attempt to re-create the changes definitely will work. This is what git stash branch newbranch does. (And it then drops the stash since it was successfully applied.)

--index的操作很容易解释，但内部有点复杂:

What the --index does is simple to explain, but a bit complicated internally:

• 进行更改时，必须先git add(或上载")它们，然后再进行commit.
• 因此，当您运行git stash时，您可能已编辑了两个文件foo和zorg，但是仅上演了其中一个.
• 因此，当您要求退回存储卡时，如果它git add是add所完成的事情而不是 git add未添加的事情，则可能会很好.也就是说，如果在执行stash之前先add编辑了foo而不是zorg，那么最好使用完全相同的设置.上演过的，应该再次上演；已修改但未上演的内容，应再次修改但不可上演.

• When you have changes, you have to git add (or "stage") them before commiting.
• Thus, when you ran git stash, you might have edited both files foo and zorg, but only staged one of those.
• So when you ask to get the stash back, it might be nice if it git adds the added things and does not git add the non-added things. That is, if you added foo but not zorg back before you did the stash, it might be nice to have that exact same setup. What was staged, should again be staged; what was modified but not staged, should again be modified but not staged.

apply的--index标志试图以此方式进行设置.如果您的工作树是干净的，通常就可以了.但是，如果您的工作树已经添加了add内容，那么您可以看到这里可能会出现一些问题.如果省略--index，则apply操作不会尝试保留整个暂存/未暂存的设置.相反，它只是使用存储袋" 中的工作树提交来调用git的合并机制.如果您不关心保留已暂存/未暂存的情况，则省略--index可以使git stash apply轻松地完成工作.

The --index flag to apply tries to set things up this way. If your work-tree is clean, this usually just works. If your work-tree already has stuff added, though, you can see how there might be some problems here. If you leave out --index, the apply operation does not attempt to preserve the whole staged/unstaged setup. Instead, it just invokes git's merge machinery, using the work-tree commit in the "stash bag". If you don't care about preserving staged/unstaged, leaving out --index makes it a lot easier for git stash apply to do its thing.

这篇关于如何恢复隐藏的未提交的更改的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！