Git Stash使用指南：原理、操作与最佳实践

1. 理解git stash的核心场景

当你正在本地分支上热火朝天地coding时，突然需要切换到其他分支处理紧急bug，但当前修改又没达到可提交的程度——这就是git stash的经典应用场景。上周我就遇到这种情况：正在重构用户模块的DAO层，突然需要切到hotfix分支处理线上支付异常。直接checkout会提示"本地修改将被覆盖"，而草草commit又会污染提交历史。

关键认知：git stash不是简单的"临时保存"，而是将工作区和暂存区的改动压入栈结构（后进先出），让工作目录恢复到HEAD提交的干净状态。

2. 完整操作流程与原理剖析

2.1 基础保存与恢复

bash复制# 保存当前工作状态（包含工作区和暂存区改动）
git stash push -m "重构用户DAO层-20240315"

# 查看存储栈列表（显示stash@{0}等引用）
git stash list

# 恢复最近一次存储（保留存储记录）
git stash apply

# 恢复指定存储（如stash@{1}）
git stash apply stash@{1}

# 恢复并删除存储记录
git stash pop

这里有个容易踩的坑：如果恢复时遇到冲突，pop操作会自动终止，但apply会保留冲突文件。建议首次恢复时先用apply确认无误后，再手动drop删除对应存储。

2.2 进阶存储技巧

bash复制# 仅存储工作区改动（不包含已add的文件）
git stash push --keep-index

# 存储时包含未跟踪文件（如新建的未git add文件）
git stash push -u

# 交互式选择要存储的代码块（类似git add -p）
git stash push -p

我曾用-p参数成功分离了混合修改：一个文件里既有调试用的临时log，又有核心逻辑修改。通过交互模式只存储了有效改动，避免了后续清理工作。

3. 典型问题排查实录

3.1 恢复时冲突处理

当存储的修改与当前分支改动冲突时：

1. 冲突文件会保留双方改动（类似merge冲突）
2. 需要手动编辑文件解决冲突
3. 执行git add <file>标记已解决
4. 继续git stash drop（如果用的是apply）

建议操作：

bash复制# 查看存储与当前文件的差异
git stash show -p stash@{0}

# 使用图形化工具解决冲突
git mergetool

3.2 误删存储恢复方案

如果误执行了git stash drop，可以通过以下步骤尝试恢复：

1. 查找git的引用日志

bash复制git reflog show stash

2. 找到对应的stash commit哈希
3. 创建新分支指向该提交

bash复制git branch recovered-stash <hash>

4. 企业级使用建议

4.1 存储命名规范

团队协作时建议采用统一命名规则：

bash复制git stash push -m "JIRA-1234_优化订单查询_<姓名缩写>"

这能避免多人协作时出现"WIP on main"这类无意义描述。

4.2 CI/CD集成方案

在自动化部署脚本中处理stash的推荐流程：

bash复制# 1. 检查是否有未提交改动
if ! git diff-index --quiet HEAD --; then
    # 2. 自动存储并记录日志
    git stash push -m "Auto-stash by CI at $(date)"
    STASH_SAVED=true
fi

# 执行正常构建流程...

# 3. 构建完成后恢复存储
if [ "$STASH_SAVED" = true ]; then
    git stash pop
fi

5. 可视化工具辅助

5.1 VS Code集成操作

1. 源代码管理视图 → 点击"..."菜单
2. 选择"Stash" → "Stash Changes"
3. 输入存储信息后确认
4. 恢复时选择"Apply Stash"或"Pop Stash"

5.2 GitKraken操作路径

1. 右键工作目录变更文件
2. 选择"Stash selected lines"
3. 在左侧Stashes面板管理存储
4. 双击或右键选择恢复方式

经验之谈：图形化工具适合简单场景，复杂操作仍建议命令行。我曾用GitKraken恢复存储时遇到编码问题，最后还是用git stash apply --index解决的。

6. 底层实现原理

git stash实际创建了三个commit：

1. 工作区改动：保存在refs/stash指向的commit
2. 暂存区状态：作为第二个parent commit
3. 未跟踪文件（当使用-u时）：作为第三个parent commit

可以通过以下命令验证：

bash复制git show-ref stash
git cat-file -p <stash_hash>

这解释了为什么git stash apply默认不恢复暂存状态——需要添加--index参数来读取第二个parent commit。

7. 替代方案对比

对于超过2天未处理的存储，我个人的习惯是：

1. 创建temp/前缀的分支
2. 将stash内容提交到该分支
3. 添加详细的commit message
4. 删除原stash记录

这样既保留了工作进度，又避免了stash栈的长期堆积。