git - 如何确定git stash的来源

Question

我有问题要做

git stash pop

因为一些dos2unix问题。我想不必合并所有只因行尾不同而不同的文件，而返回到存储区工作。
我想做完之后再去储藏室

git checkout BRANCHNAME

但我不知道如何确定代表这个藏物起源的分支名称。
有人知道吗？

Answer 1

TL；博士
使用git stash branch创建新分支并应用存储：

git stash branch newbranch

这总是有效的（好吧，只要您的当前状态都是干净的：请参阅下面的“长”部分），相当于创建一个新分支，其父分支是您进行存储时的当前提交，然后运行 git apply --index（这意味着它将分别还原索引和工作树）。
对这个问题的直截了当的回答
您需要做的只是找出是否有任何分支名称标识出与所讨论的存储的父级相同的提交，因此：

git for-each-ref --format='%(refname:short)' \
    --points-at $(git rev-parse refs/stash~1) refs/heads

将查找可能的分支名称（如果有）。（这依赖于相对现代的 git for-each-ref特性）
长
每一个存储本身只有两个（有时是三个）提交。 git stash所做的是使这两个（或三个）提交，但不将它们放在分支上。
git中的branch这个词本身有点模棱两可（参见 What exactly do we mean by "branch"?），但在这里，我们使用它的意义是，像 master或 develop这样的分支名称只是指向其分支上的最后一次提交：

...--E--F--G   <-- master
         \
          H   <-- develop

当您 git checkout一个类似于 develop的分支名称时，您告诉git：
将提交的内容提取到索引中（构建下一次提交的位置，也称为暂存区域，有时称为缓存）
将现在未冻结但仍然是git表单/压缩文件的文件从索引中取出，并将它们复制到工作树中，您可以在其中处理它们。
将名称 HEAD附加到分支名称，以便git知道您现在签出了哪个提交：

...--E--F--G   <-- master
         \
          H   <-- develop (HEAD)

现在git知道散列为 H的提交是当前的或 HEAD提交，正如名称 develop所指。
如果此时执行普通的新提交（通过将更新或新文件从工作树复制回索引/暂存区域，然后运行 git commit将其冻结为新提交），git将以当前提交为其父级写入新提交，然后更新分支名称：

...--E--F--G   <-- master
         \
          H--I   <-- develop (HEAD)

名称 HEAD仍然附加到分支名称，但现在分支名称标识commit I，而不是commit H。
git stash所做的是使两个提交一个用于索引，一个用于没有分支名称的工作树。相反，git使用名称 refs/stash来查找 w提交（而 w同时查找原始提交和 i提交）：

...--E--F--G   <-- master
         \
          H   <-- develop (HEAD)
          |\
          i-w   <-- refs/stash

保存 i和 w提交后， git stash将运行 git reset --hard，以将索引和工作树设置回与当前提交匹配的状态（此处为 H）。
在这种情况下，此时，隐藏的父提交也由现有的分支名称“cc”指向。但是假设您已经完成了这个 develop，然后进行了一组不同的更改并进行了一个新的提交 git stash？那么你有：

...--E--F--G   <-- master
         \
          H--I   <-- develop (HEAD)
          |\
          i-w   <-- refs/stash

现在没有指向现有的、历史提交 I的分支名称，即使这是保证应用“cc>”的一个提交。
因此，如果您的索引和工作树现在是干净的（即，匹配附加了 H的commit refs/stash的内容），并且您现在运行了 I，那么 HEAD将要做的是附加一个新的分支名称 git stash branch recover，以提交 git stash，并签出该提交并通过附加 recover使新分支成为当前分支：

...--E--F--G   <-- master
         \
          H   <-- recover (HEAD)
           \
            I   <-- develop

并且，作为 H操作的最后一步，应用并删除存储，以便索引恢复到您签出并运行 HEAD时的索引方式，并且工作树恢复到您签出并运行 git stash branch时的工作树方式。现在您可以完成 Hing和 git stash以进行新的提交：

...--E--F--G   <-- master
         \
          H--J   <-- recover (HEAD)
           \
            I   <-- develop

如果 H仍然指向commit git stash？
如果你还没有移动上一个分支，好吧，现在你有了一个新的分支。也就是说，现在您将拥有：

...--E--F--G   <-- master
         \
          H   <-- develop
           \
            J   <-- recover (HEAD)

（我在这里将新的提交保留为 git add，以便更容易地将其与前面的关系图匹配起来）。这个设置没有问题。当然，如果您不想在这里使用 git commit分支，您不必使用 J，但它仍然有效。
那三个犯罪藏匿处呢？
三个提交存储是由 develop（ H）或 J（ recover）生成的。应用（或弹出）这样的隐藏要求第三次提交中的文件不会与工作树中的文件冲突。一般来说，这意味着工作树不仅必须根据 git stash branch是“干净的”，而且还必须根据使用适当选项运行 git stash save -a所提供的意义是干净的。在这种情况下，即使 --all有时也会失败。如果它真的失败了，它就不会让藏起来的东西爆炸。
有关更多信息，请参见 Why does git stash pop say that it could not restore untracked files from stash entry?