我什么时候应该使用git stash save
而不是git stash push
,反之亦然?
git stash save
命令接受一个非选项参数,即储藏信息。
git stash push
命令可以使用选项 -m
来指定储藏信息,同时也可以将一系列需要储藏的文件作为参数传入。
save
命令是为了向后兼容而保留的,但最终将被 push
命令取代。 - void.pointer为了明确起见,从Git 2.15/2.16(2018年第一季度)开始,git stash save
已被弃用,取而代之的是git stash push
(尽管git stash save
目前仍可用)。
请参见commit c0c0c82,commit fd2ebf1,commit db37745(由Thomas Gummerer(tgummerer
)于2017年10月22日提交)。
(由Junio C Hamano -- gitster
--于commit 40f1293,2017年11月6日合并)
stash
: 标记 "git stash save
" 在手册页中已弃用'git stash push
' 修复了 'git stash save
' 接口中的历史瑕疵。
由于 'git stash push
' 具有更好、更一致的用户界面,同时拥有 'git stash save
' 的所有功能,因此将 'git stash save
' 标记为已弃用。
stash
: 删除 "stash push
" 中现在多余的帮助信息使用 'git stash save
' 接口时,用户很容易尝试添加以 "-
" 开头的消息,这会被 'git stash save
' 解释为命令行参数并失败。
针对这种情况,我们添加了一些额外的帮助信息,说明如何创建以 "-
" 开头的消息的储藏。
对于 'stash push
',消息通过 -m
标志传递,避免了这种潜在的问题。
现在只有以 "-
" 开头的路径规范需要使用 "-- --<pathspec>
" 来与命令行参数区分开来。
这在 git 命令行界面中相当常见,我们不会尝试猜测用户在其他情况下想要什么。
由于这种传递路径规范的方式在其他 git 命令中非常常见,并且我们没有提供任何额外的帮助信息,因此在 'git stash push
' 的错误消息中也是如此。
自 Git 2.18(2018年第二季度)开始,命令行补全(在contrib/
中)已经了解到"git stash save
"已被弃用("git stash push
"是新世界中的首选拼写),并且不会将其作为可能的补全候选项提供,当"git stash push
"可以使用时。
请参见 commit df70b19,commit 0eb5a4f(由Thomas Gummerer(tgummerer
)于2018年4月19日提交)。
(由Junio C Hamano -- gitster
--合并于commit 79d92b1,2018年5月8日)
completion
: 使stash -p
成为stash push -p
的别名我们在manpage中将'git stash -p
'定义为'git stash push -p
'的别名。在完成脚本中也要这样做,这样当用户使用'git stash -p --<tab>
'时,所有可以给'git stash push
'的选项都会被自动补全。
目前,用户将获得的唯一附加选项是'--message
',但未来可能会有更多。
命令行自动完成脚本(在contrib/
中)试图将"git stash -p
"作为"git stash push -p
"进行自动完成,但这太过于激进,还影响了"git stash show -p
",已经在Git 2.28(2020年第三季度)中得到了修正。
请参见commit fffd0cf(2020年5月21日),作者为Ville Skyttä(scop
)。
(由Junio C Hamano -- gitster
--于commit a8ecd01合并,2020年6月9日)
completion
: 不要用-p
覆盖给定的stash子命令签名:Ville Skyttä
df70b190(“completion
: make stash -p and alias for stash push -p”,2018-04-20,Git v2.18.0-rc0 -- merge listed in batch #5)希望确保"git stash -p <TAB>
"提供与"git stash
push -p <TAB>
"相同的补全,但是它通过在命令行上找到-p
选项时强制将$subcommand
设置为"push
"来实现。
这会损害任何可以使用"-p
"选项的子命令,即使已经明确给出了子命令,例如"git stash show -p
",更改添加的代码也会覆盖用户给出的$subcommand
。
修复方法是确保只有在尚未给出$subcommand
时才默认为"push
"。
通过“git stash save”接口,用户可以轻松地尝试添加以“-”开头的消息,而“git stash save”会将其解释为命令行参数并失败。 […]
对于“stash push”,消息使用“-m”标志传递,避免了这种潜在问题。现在只有以“-”开头的路径规范需要使用“--<pathspec>”进行与命令行参数的区分。这在git命令行界面中非常常见,我们不会在其他情况下猜测用户的意图。
“git stash push”具有“git stash save”的所有功能,并具有更好、更一致的用户界面。
git stash push
所取代。它与“stash push”的区别在于它不能采用pathspec。相反,所有非选项参数都被连接起来形成贮藏信息。push
还有一种简短的形式,其中 "push" 被省略在 stash
命令中。而 save
命令则没有这样的等效形式。根据文档:
为了快速创建快照,您可以省略 "push"。在此模式下,不允许使用非选项参数,以防止拼写错误的子命令导致不必要的存储条目。两个例外是
stash -p
,它的作用相当于stash push -p
和路径规范元素,它们允许在双破折号--
后使用以消除歧义。
git stash
git stash -p
通过阅读文档,我认为这应该是两个命令的相当完整的比较:
push |
save |
---|---|
git stash push |
git stash save |
git stash push -m <message> |
git stash save <message> 或 git stash save -m <message> |
git stash push -m <message> (消息以“-”开头) |
git stash save -m <message> |
git stash push [--] <pathspec>… |
N/A(不可能) |
git stash push --pathspec-from-file=<file> |
N/A(不可能) |
git stash |
git stash save |
git stash -p |
git stash save -p |
git stash -- <pathspec>… |
N/A(不可能) |
save
和 push
之间的显著变化包括:
push
创建部分存储区(partial stash),但不能使用 save
。路径规范可以作为内联参数提供,也可以使用 --
提供。save
,但必须通过 -m
在 push
中提供。
git stash push
和git stash save
视为类似的东西,但不完全相同。它没有解释它们之间的区别(至少我没看懂)。请参考https://git-scm.com/docs/git-stash。 - David Bursongit stash push
是git stash save
的新同义词,但选项已经规范化。此外,您可以限制哪些路径被隐藏(并随后重置),而这在“保存”操作中是无法实现的。 - torek