TL;DR:改用git worktree。
无论你是 Git 新手,还是经验丰富的 Git 用户,我都推荐避免git stash。原因很简单:
-
git stash 通过制作工作提交.
-
git commit还通过提交来工作。
git stash 有什么特别之处——嗯,第一的有什么特别之处——它所做的提交是在没有分支. (在 Git 中,提交不必在任何分支上,任何一个特定的提交都可以在许多同时分支,因此在 Git 存储库中实际上不需要分支。我们——人类——使用分支名称,因为 Git 用于单个提交的名称是那些大而丑陋的随机散列 ID,我们是坏的在。快速:c3ff4cec66ec004d884507f5296ca2a323adbbc5 和 c3ff4cec66ec004d884507f5276ca2a323adbbc5 是相同的还是不同的? main 与 feature 怎么样,它们是相同的还是不同的?1)
git stash 提交的其他特别之处是:
- 他们在没有分支,所以它们很容易从一个分支移动到另一个分支;
- 他们在没有分支, 所以他们很难寻找并保持笔直;
- 它们以“藏匿丛”的形式出现,或者我有时喜欢称之为“藏匿袋”,这意味着只有
git stash 命令才能正确处理它们;
- Git 的其余部分将处理隐藏提交仿佛这是一个合并提交,因为从技术上讲,由 stash ref 命名的提交是合并提交,除非它在被视为合并提交时无法正常工作,这意味着没有其他 Git 命令可以与它们一起正常工作。
其中之一是一件好事:存储很容易从一个分支“移动”到另一个分支。其余的都是非常糟糕的、不好的、可怕的、可怕的事情。例如,如果你错误地运行 git show stash 而不是 git stash show,你经常会看到没有什么. Git 悄悄地假装你有一个空的存储,即使你没有。
所以这就是为什么你应该避免git stash。只是不要使用它!
如果你必须但是,使用它,请记住:git stash 通过制作提交,然后 - 已提交保存工作树的状态 - 它运行 git reset --hard 以清除所有工作。该工作安全地保存在 stash 提交中,但现在只有 git stash 可以取回它。
它是可以使用git stash -p,作为eftshift0 notes in a comment。但是有一个更好的方法,如果你的 Git 至少是 2.15 左右(最好是 2.17 或更高版本):它被称为 git worktree。2
使用git worktree add,您可以创建一个二、分离工作树那是在其他一些分支上。假设您在创建的新分支 feature/thingy 上,并且您正在编辑文件 routines.py 并意识到您应该在不同的现有或新分支中执行某些操作。只需运行:
git worktree add -b feature/new-feature ../new-feature main
在 ../new-feature 的新分支 feature/new-feature 上创建一个新的工作树,该分支从现有分支 main 产生。然后您可以启动一个新的终端窗口和cd ../new-feature 并在另一个分支上的该终端会话中工作,同时不理会当前的终端会话,以便您可以继续在feature/thingy 上工作。
(Pycharm 或任何其他 IDE 是否可以处理 git worktree 是一个单独的问题。我通常避免使用 IDE,因为它们往往擅长一事情和糟糕的在其他所有事情上,我喜欢随时都有很多好的工具可用。)
1或许更公平一点:main vs maim,或者main vs marn 怎么样?
2git worktree 命令是在 Git 2.5 中引入的,但在 Git 2.15 之前它有一个特别讨厌的小错误。一些较小的错误也在随后的几个版本中得到修复,这就是为什么我在这里推荐至少 2.17。