这是情况:
git stash 在分支 A git checkout B git stash 在分支 B git checkout A git stash pop 在分支 A 在上面列表的第 7 步之后，我在存储之前在分支 A 上所做的更改没有回来，但我在分支 B 上所做的更改在分支 A 上 pop 。我在分支 A 上使用了
cmd z 并且文件进入了以前的状态，其中有我所做的更改。似乎分支 A 的 HEAD 移动到分支 B 的 HEAD。当我在该分支上 git checkout B 和 git stash pop 时发生同样的情况:分支 B 在分支 A 上进行了所有更改，但没有在分支 B 上所做的更改。我使用cmd z 再次恢复到我需要的分支状态。这在一段时间内给我带来了很多问题，直到我被允许再次在项目上提交代码(暂时没有人可以提交，因为在提交时自动推送到服务器并且经理不希望在项目中添加新代码)服务器，直到他们运行了一些测试)。我怎样才能只 pop 在分支上所做的更改而不是在其他分支上所做的更改？
最佳答案
git stash 所做的是进行一次 commit.1
当然，git commit 所做的是提交。那么为什么我们有 git stash 呢？
这些命令之间的一个显着区别是 git stash 所做的提交不在任何分支上。这允许您在一个分支上时 stash，然后移动到另一个分支并在那里应用存储。换句话说，它可以让您移动正在进行的工作。
无论如何，您通常可以(但并非总是)移动正在进行的工作。见 Git - checkout another branch when there are uncommitted changes on the current branch 。但是，当您不能这样做时，您可以使用 git stash 来处理此问题。
另一方面，如果你想“藏在一个分支上”，就像你的情况一样，你可能最好只进行常规提交，而不是特殊的 stash 提交。这样的提交更容易处理，也没有 a bug that git stash has 。您不太可能遇到此错误，但“定期提交更简单，更容易处理”(在分支上提交，与 stash )是避免 git stash 的一个很好的理由。
如果您无论如何更喜欢使用 git stash，请注意每个新的存储“将”前一个“推”到“存储堆栈”中更高的位置。旧的 stash 变为 stash@{1} ，而 stash@{1} 变为 stash@{2} ，依此类推。当你drop(丢弃)或pop(尝试应用，然后丢弃) stash ，堆积的人在它上面移动回落，所以如果你是git stash drop stash@{3}当你不得不为好，你会留下stash@{4}和stash@{5}与stash@{3}和现在是 stash@{4}。
您可以这样命名任何存储，包括最近的存储: stash@{0} 与 stash 的含义相同。 (Git 实际上使用 stash 的 reflog 实现了所有这些。)
1事实上，它至少进行两次提交，有时是三次。两次提交存储索引和工作树状态；第三次提交(如果存在)来自 -u 或 -a 并存储未暂存( -u )或所有( -a )文件。工作树提交是一个非常奇怪的 merge 提交，索引提交作为它的第二个父级，第三个提交(如果存在)作为它的第三个父级。工作树提交的第一个父级以及索引提交的唯一父级是您运行 git stash 时当前的提交。
如果你绘制提交图片段——每当你在 Git 中做任何复杂的事情时，这是一个好主意——索引和工作树提交对有点悬在原始提交之外，refs/stash 引用指向这对, 而不是分支名称。它看起来几乎像一个小手提包，或者卡在 Twig 上以防止熊进入的食物储藏室，或者类似的东西，所以我喜欢把它称为“stash 袋”。
关于Git stash 两个分支，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/38034151/