git stash适用于临时保存CI/CD脚本、Dockerfile、.env、Ansible playbook等环境配置变动，核心是用-u或-a参数暂存未跟踪文件，确保工作区干净且不丢失调试修改。
在 Linux 环境中，用 git stash 临时保存自动化环境配置变动（比如 CI/CD 脚本、Dockerfile、.env 临时修改、Ansible playbook 调试变更等），核心目标是：**让工作区变干净，避免切换分支或拉取更新时因配置文件冲突导致操作中断，同时不丢失调试中的配置调整**。
哪些配置变动适合 stash？
典型场景包括：
- 本地调试用的
.env或config/local.yml中临时改了数据库地址、API 密钥开关 - CI 流水线脚本（如
.github/workflows/test.yml）加了 debug 步骤，尚未完成验证 - Dockerfile 中临时替换了基础镜像（
FROM python:3.11-slim→FROM python:3.11-debug）用于排查构建失败 - Ansible
group_vars下某台测试机的变量被手动覆盖，但还没抽象成 role 或条件逻辑
关键操作：带选项暂存，避免漏掉未跟踪配置文件
默认 git stash 只保存已跟踪文件的修改。而环境配置常含新创建的临时文件（如 .env.local）、或被 .gitignore 排除的调试文件（如 secrets.temp）。必须显式带上参数：
-
git stash push -u -m "ci: add debug logs to deploy workflow"→-u（--include-untracked）包含所有未跟踪但非忽略的文件 -
git stash push -a -m "docker: test multi-stage build with debug layer"→-a（--all）连.gitignore里的文件（如node_modules/、logs/）也暂存（慎用，仅限完整环境快照） - 若只暂存部分配置（如只存 Dockerfile 和 .github/workflows），可指定路径：
git stash push -m "docker+ci: temp patch" -- Dockerfile .github/workflows/
恢复时注意配置文件的上下文一致性
环境配置往往强依赖当前分支状态。例如你在 feature/db-migration 上改了 docker-compose.yml，切到 main 后用 git stash apply 恢复，可能因 main 缺少对应服务定义而报错。建议：
- 优先用
git stash pop在原分支恢复，避免跨分支直接应用 - 若必须在其他分支用，先检查差异：
git stash show -p stash@{0}，确认没有硬编码分支专属路径或变量 - 恢复后若出现冲突（如
.env与远程版本不兼容），Git 会标出 git add 后再继续
清理与安全习惯
自动化配置变动常带敏感信息（密钥、token、内网地址），stash 不加密且仅存本地，务必及时清理：
- 用
git stash list定期查看，带-m描述的 stash 更易识别用途 - 确认某次调试配置已无用后，立即执行：
git stash drop stash@{2} - 禁止长期保留含密钥的 stash；更安全的做法是：用
git stash --patch交互式暂存，跳过敏感行 - 团队协作中，绝不依赖 stash 代替分支管理——紧急修复应走
git stash branch hotfix/xxx创建独立分支处理
