【问题标题】:Is git stash branch-specific or for the whole repository?git stash 是特定于分支还是整个存储库?
【发布时间】:2013-12-29 20:26:58
【问题描述】:

我走进一家分店,做了一些工作。我想进入另一个分支但不想提交,所以我做了git stash。然后我做了git checkout <otherbranch>。我在那里做了一些工作,就像在第一个分支中一样,我想在提交工作之前退出它。所以我也在那里做了git stash。我切换回第一个分支并尝试取消存储它(git stash pop),认为它会从该特定分支获取存储。我很惊讶它从<otherbranch>(最新的藏匿处)中取出藏匿处。我的印象是 stash 是特定于分支的,但这种行为表明整个本地存储库只有一个 stash。

git stash 是特定于分支还是整个存储库?如果是针对整个存储库,我可以将选项传递给它以使其特定于分支吗?

【问题讨论】:

    标签: git git-stash


    【解决方案1】:

    我不确定为什么这里的每个答案都建议用commit+reset 模拟 stash。 Stash 非常好用。

    这里是存储工作流程:

    当你不得不切换分支并且你还没有准备好提交时,将你的更改保存到堆栈中

    git stash save "Your custom stash message"
    

    (如果您不想要自定义消息,只需使用git stash)。

    当你返回一个分支时,你可以看到这样的 stash 列表:

    git stash list
    

    如果您在分支FixIssue0203 上,则可以使用git stash pop,因为这将应用顶部stash@{0} 并将其从存储中删除。

    但是,如果您的 in 分支 ImproveReadme 您应该首先应用 stash 1 git stash apply stash@{1},然后从堆栈 git stash drop stash@{1} 中删除 stash 1。

    就是这样!

    【讨论】:

      【解决方案2】:

      git stash 不是每个分支。

      • 而不是git stash(当你有很多藏匿处和分支时很容易丢失)
      • 我建议使用git commit 将未完成的代码保存在您的分支中,并在您准备好完成代码时使用git reset ${COMMIT_HASH_VALUE} 以取回未完成的代码
      • git commitgit reset 正确一起使用可以模拟特定分支的git stash

      这是一个常见的真实场景,展示了commitreset 命令的价值和用法:

      • 您正在处理功能分支 X,而您的代码甚至没有编译或通过测试
      • 存在比当前新功能优先级更高的错误,因此您必须立即着手修复错误
      • 而不是 git stash(因为您有很多 stash 和许多分支,所以 stash 会在混合中丢失)
      • 您可以在功能分支 X 上执行 git commit
        • 写下COMMIT_HASH_VALUE 以备后用
      • 签出新的分支 Y 以获取热修复
      • 在分支 Y 上完成热修复(执行合并请求以将热修复放入基线并删除热修复分支)
      • 然后再次检查功能分支 X
      • 弹出未编译或未通过测试的未完成工作 --> 只需执行 git reset ${COMMIT_HASH_VALUE}

      (仅供参考,git reset 的默认值为 --mixed

      【讨论】:

      • 在这种情况下重置的便捷快捷方式是git reset HEAD~1
      • @samHH 我有一个太多的实例,git reset HEAD^1 不小心被击中了两次......所以我选择不使用HEAD^1HEAD~1
      • 如果 stash 不是特定于分支的,为什么它会告诉你“在 BranchName 上”?只是为了帮助您跟踪它的来源?
      【解决方案3】:

      查看当前的存储堆栈:

      git stash list
      

      要从堆栈中选择特定的存储,请通过上面显示的stash@{<em>number</em>} 引用它。

      如果您希望每个分支的行为,您可以只在分支上进行一次提交(或多次提交)。您可以随时“取消”提交(例如,使用git reset--soft--mixed;参见git reset documentation;或使用git rebase -i 以仅保留最终的“真实”提交( s)同时丢弃临时)。

      (要真正模拟git stash,您至少需要两次提交,一次用于索引状态,一次用于工作树状态。但是,如果您不打算保存和恢复索引状态,则可以git add -A 整个工作树状态并将其放入临时提交中。或者,git stash 是一个 shell 脚本,因此您可以很容易地复制和修改它,使其默认在每个分支上工作,例如使用 @ 987654332@ 作为其工作命名空间,而不是整个仓库的单个全局 refs/stash。您仍然可以通过显式命名将存储从一个分支带到另一个分支。)

      【讨论】:

      • 除了描述之外,你知道如何显示每个stash list项目的文件列表吗?
      • git stash show(或git stash show stash@{&lt;number&gt;} 用于@{0} 版本以外的其他内容)为您提供diff --stat;添加-p 以获得更大的差异。注意:这会将"stash bag" 中的“工作树”与其挂起的提交进行比较;没有前端界面可以查看给定存储包中的“索引”中的内容。
      【解决方案4】:

      没有。git stash 是每个存储库的。

      Here 是一个关于如何使用它的好页面。

      【讨论】:

      • 第二个存储是否会覆盖第一个? IOW,如果我做了两次 stash,但中间没有 unstash,我会丢失第一个 stash 吗?
      • 不,你会得到一堆(后进先出)的存储。你将一个存储推入你的存储堆栈,然后另一个然后你弹出第二个然后你弹出第一个,等等。
      • “No and No”是一个令人困惑的答案,因为 OP 的第一个问题是非此即彼。
      猜你喜欢
      • 2014-04-17
      • 1970-01-01
      • 2020-03-31
      • 2020-06-27
      • 2019-01-17
      • 2014-03-31
      • 2020-12-28
      • 2015-12-17
      • 2013-01-30
      相关资源
      最近更新 更多