详细介绍Git临时保存分支修改之git stash（开发利器）

git stash 这个命令，用得好是利器，用错了却容易埋坑。先说一个核心判断：git stash push -m 是目前唯一被官方推荐的保存方式，老手们基本都已经切换到这条路径上来了。 别再用 git stash sa ve 了——从 Git 2.19 开始它就被标记为 deprecated，只是 Git 团队出于兼容性考虑还没直接移除。如果你在团队协作或新项目里还捧着旧语法，踩坑是迟早的事。举个例子：想包含未跟踪文件时得加 -u 参数，但 git stash sa ve -u 会直接给你甩一句 “unrecognized argument: -u”，报错、中止、毫无商量余地。 你可能会问：描述信息真的有必要吗？来，设想一个场景——你连续 stash 了四五次，跑完 git stash list 一看，满屏都是 stash@{0}、stash@{1} 这种编号，过两天再回来，谁还记得哪条对应哪个功能？加上 -m 之后情况完全不同，一条命令直接看清上下文：

stash@{0}: On feature/login: WIP: add password strength check
stash@{1}: On main: fix: typo in error message

具体用法其实很简单： - git stash push -m "WIP: login UI" —— 默认只保存已跟踪文件的修改 - git stash push -u -m "WIP: login UI + config files" —— 加 -u 才能把新增但未 git add 的文件也纳入暂存 - git stash push --keep-index -m "WIP: partial refactor" —— 暂存工作区修改，但暂存区原封不动保留着，适合只 stash 掉尚未 add 的部分

git stash apply 和 git stash pop 的关键区别

恢复 stash 时，这两条命令看似兄弟，行为差异却容易被忽视。简单说：git stash pop ＝ git stash apply + git stash drop。但这个“自动删除”并非原子操作——如果恢复过程中发生冲突，pop 会失败并中止，stash 照样留在栈里；而 apply 即使在冲突发生也照常执行，stash 始终保留不动。 这意味着：pop 更适合确定无冲突的干净场景，比如你确定刚 stash 完就没动过工作目录。而 apply 更安全，尤其当你不确定当前工作区是否干净，或者想反复测试某次 stash 内容时。 - 想试完就删：用 git stash pop - 想保留 stash 备份，或准备多次 apply 同一个 stash：必须用 git stash apply - 恢复指定 stash（比如第二条）：git stash apply stash@{1}。注意编号从 0 开始，stash@{0} 是最新一条

stash 冲突时该怎么处理

stash 恢复本质上是一次三方合并（base 是 stash 创建时的 HEAD，ours 是当前工作区，theirs 是 stash 内容），所以冲突处理和 git merge 一样需要手动解决。但有个很容易被忽略的细节：冲突后 git status 显示的是 “both modified”，而不是你预想中的 “unmerged paths”，容易让人误以为根本没冲突。 真正要盯住的是命令行输出——只要看到 “Auto-merging xxx” 后面紧跟着 “CONFLICT” 字样，就必须立刻 git add 解决后的文件，再执行 git stash drop（如果是 apply）或等 pop 自动完成。 - 冲突文件会进入工作区，内容含 <<<<<<< Updated upstream 和 >>>>>>> Stashed changes 标记 - 解决后别忘了 git add ，否则 git stash drop 会拒绝执行——Git 认为还有未处理的修改 - 如果想放弃这次恢复：git reset --hard 回退到恢复前状态，再 git stash drop stash@{0} 清理掉已失效的 stash

stash 不是长期备份，别依赖它跨周保存

stash 存在本地 Git 仓库的 reflog 中，既不参与 git push，也不会同步到远程。一旦你不小心执行了 git stash clear，或者 reflog 过期（默认 30 天），所有 stash 就会彻底消失，连 git fsck 都找不回来。 更隐蔽的风险在于：stash 基于创建时的 commit ID。如果那个 commit 之后被 rebase 或 filter-branch 删除，stash 就会变成“悬空引用”——git stash show 可能报错，apply 时也可能应用到错误的上下文。 所以，超过一天的临时修改，建议至少做一次 git commit -m "wip: xxx" 并推送到个人分支。stash 只适合小时级上下文切换，绝不是替代 commit 的方案。