情况如此：
git stash git checkout B git stash git checkout A git stash pop 在上面列表的第7步之后，我在存储之前对分支A所做的更改没有回来，但是我在分支B上做出的更改在分支A上弹出。我在分支A上使用cmd z并且该文件进入了以前的状态，该状态有我所做的更改。似乎分支A的HEAD移动到分支B的HEAD。当我git checkout B和git stash pop在该分支上时发生了同样的事情：分支B在分支A上进行了所有更改但不是更改我在分支B上做了。我再次使用cmd z恢复到我需要的分支状态。
这导致了我很多问题，直到我被允许再次在项目上提交代码（没有人可以提交一段时间，因为在提交时有一个自动推送到服务器而经理没有想要在服务器中使用新代码，直到他们运行一些测试）。如何只弹出分支本身所做的更改而不是其他分支上的更改？
答案 0 :(得分：4)
git stash做的是提交。 1
当然，git commit做的是提交。那么我们为什么要git stash呢？
这些命令之间的显着差异在于，git stash提交的提交不在任何分支上。这允许您在一个分支上stash，然后移动到另一个分支并在那里应用存储。换句话说，它可以让您移动正在进行的工作。
无论如何，您可以（但不总是）继续进行正在进行的工作。见Git - checkout another branch when there are uncommitted changes on the current branch。但是，当无法时，您可以使用git stash来解决此问题。
另一方面，如果你想隐藏在一个分支上，就像在你的情况下一样，你可能最好只进行常规提交，而不是特别的存储提交。这样的提交更容易处理，也没有a bug that git stash has。你不太可能遇到这个bug但是＃34;常规提交更容易处理＆＃34; （提交分支，与stashes相比）是避免git stash的一个很好的理由。
如果您仍然希望使用git stash，请注意每个新的藏品＆＃34;推送＆＃34;之前的那些在＆＃34;藏匿堆栈中更高？＃34;。旧存储变为stash@{1}，stash@{1}变为stash@{2}，依此类推。当您drop（丢弃）或pop（尝试申请，然后弃置）藏匿时，其上方堆叠的藏匿物会向下移动 - 如果您git stash drop stash@{3}时stash@{4} {1}}和stash@{5}同样，您现在可以选择stash@{3}和stash@{4}。
您可以通过以下方式命名任何存储，包括最近的存储：stash@{0}与stash的含义相同。 （Git实际上使用stash的 reflog 来实现所有这些。）
1 事实上，它至少提交了两个提交，有时提交了三个。两个提交存储索引和工作树状态;第三个提交（如果存在）来自-u或-a，并存储未分级（-u）或所有（-a）文件。工作树提交是一个非常奇怪的合并提交，索引提交作为其第二个父级，第三个提交（如果存在）作为其第三个父级。工作树提交的第一个父项和索引提交的唯一父项是运行git stash时的当前提交。
如果你绘制提交图片段 - 每当你在Git中做任何复杂的事情时，这是一个好主意 - 索引和工作树提交对有点悬挂在原始提交之上，{{1引用指向该对，而不是分支名称。它看起来几乎像一个小手提包，或挂在树枝上的食物缓存，以防止它远离熊，或一些这样的，所以我喜欢把它称为一个＆＃34;藏匿袋＆＃34;。
答案 1 :(得分：0)
Torek（像往常一样）提供了一个很好的答案，但我相信这里简洁的答案只是要注意隐藏包含数据作为堆栈（LIFO）。因此，当你推动A的工作然后B的工作时，它首先弹出B然后是A.所以当你回到A然后做第一次弹出时，你得到了保存的B工作。
答案 2 :(得分：0)
弹出一个存储重新应用最后一个存储，无论你藏哪个分支！因此，您发布的问题是在分支B上创建的最后一个存储重新应用于分支A.下一次，您必须指定要弹出的存储。
解决给定问题：
这就是全部。
答案 3 :(得分：0)
如果您输入 git stash list，系统会根据您的特定情况显示类似内容
stash@{0}: WIP on branch-b
stash@{1}: WIP on branch-a
输入 git stash pop 将始终获得 stash@{0} 节点。
因此，如果您在 branch a 并且想要在该分支中应用您的进度。根据列表，您应该输入：
git stash pop stash@{1}