Git Stash的新分支会影响其他存储吗? [英] New branch from Git Stash will affect other stashes?

问题描述

我有一个master分支，在该分支上隐瞒了多个更改，现在我想根据{0}处的隐隐更改创建一个新分支.但是我怀疑创建新分支不会影响我的其他存储，因为 git 将在创建新分支后删除我的存储.是 git 只会在{0}索引处丢弃存储区，还是会丢弃所有存储区?隐匿的变化对我来说太重要了.

I have the master branch on which I stashed multiple changes and now I want to create a new branch from the stashed changes which are at {0}. But I doubt that creation of the new branch will not affect my other stashes, because git will drop my stash after creation of the new branch. Will git only drop stashes at {0} index or will it drop all of the stashes? The stashed changes are too IMP for me.

推荐答案

简短答案:不用担心，隐藏条目彼此独立.去吧.

Short answer : No worries, stash entries are independent from one another. Go for it.

更长的答案 :(带有直观示例)

Longer answer : (with a visual example)

为说明情况，可以将隐藏项视为不相关提交的列表，每个提交都指向回购树中的不同点.

To help picture it, the stash can be viewed as a list of unrelated commits, each pointing to different points in the repo tree.

请参见下面的假设情况

        F---G <<< feature/abc
       /
      /           H---I <<< bugfix/123
     /           /     \
A---B---C---D---E---F---J <<< master
         \
          \
           K---L---M <<< feature/xyz

以及以下假设情况

在这些不同的分支上工作时，您在过去的几天中多次隐藏了更改.

You stashed changes a number of times during the last couple of days, while you were working on these different branches.

假设您藏了3次:

• 在第一次尝试提交 G 时，一次使用 feature/abc ，因为您对第一种方法完全不满意，但希望将其放在手边情况.

• once on feature/abc during your first attempt at committing G because you were unsatisfied with your first approach altogether but wanted to keep it at hand just in case.

然后，您在提交 H 后有点时间在处理bugfix/123时被打断，并且不得不切换分支.后来您回到了 bugfix/123 ，然后应用了 git stash 而不是 git stash pop 来使条目在该stash中保持活动，以便以后使用重用/检查.

then you were interrupted while working on the bugfix/123, a bit after having committed H, and had to switch branches. Later you came back to bugfix/123 then did a git stash apply rather than git stash pop to keep the entry alive in the stash for later reuse/inspection.

最后

• 在 feature/xyz
上工作时，必须在 L 之后再次藏匿

(操作按该顺序进行.)

(The operations happened in that order.)

造成的藏匿情况

这时您的藏匿处清单看起来像

At this point your stash list would look like

stash@{0}: WIP on feature/xyz: f1d6b3a unfinished - get rid of var dumps
stash@{1}: WIP on hotfix/123: 94722ae unfinished - css still broken
stash@{2}: WIP on feature/abc: 4fb4785 no good - test T1 failed

但重要的是，因为存储项是父项的条目，所以无论HEAD指向哪个提交项，父项都将作为父项:

but the important point is that, since a stash entry takes for parent whichever commit HEAD points to when the entry is made :

L 是 f1d6b3a 的父级(我们称其为 L')
H 是 94722ae 的父代(我们称其为 H')
F 是 4fb4785 的父代(我们称其为 F')

L is the parent of f1d6b3a (let's call it L')
H is the parent of 94722ae (let's call it H')
F is the parent of 4fb4785 (let's call it F')

可以图片为

          F' <<< stash@{2}
         /
        F---G <<< feature/abc      H' <<< stash@{1}
       /                          / 
      /                          H---I <<< bugfix/123
     /                          /     \
A---B---C---D------------------E---F---J <<< master
         \
          \
           K---L---M <<< feature/xyz
                \
                 L' <<< stash@{0}

那么，很容易看到它们虽然在您的 stash列表中顺序列出，但实际上它们是无关的.

Then it's much easier to see that although they're listed sequentially in your stash list, they're in fact unrelated.

这篇关于Git Stash的新分支会影响其他存储吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！