首页/开发/Git 与协作速查/git rebase --autostash 自动寄存改动
合并变基与冲突71 条

git rebase --autostash 自动寄存改动

变基前自动把未提交改动暂存、结束后恢复,避免因工作区不干净而中断;结果冲突时需手动处理恢复的改动。

Git 与协作速查开发更新于 2026-10-13

变基自动寄存是什么

变基开始前自动把未提交的改动存入暂存区,结束后再恢复,避免因工作区不干净而中断。它适合「改到一半需要同步主干」这类场景:不用手工暂存再恢复,代价是恢复时的冲突会以工作区改动形式出现,需要自己处理。

基本信息

用途免去手工暂存再变基的步骤
语法git rebase --autostash <上游>
持久开关git config rebase.autoStash true 让所有变基默认启用
生效时机变基开始时自动寄存,结束后自动恢复
中断处理中途中止时改动回到工作区或仍留在暂存列表

典型使用场景

  • 改到一半需要把分支对齐到最新主干
  • 切换任务前不想提交半成品代码
  • 临时拉取上游改动后继续手头的开发
  • 自动化脚本里同步分支,不希望因脏工作区失败
  • 同时在多个分支间穿插小改动

常用示例

常用示例
git rebase --autostash origin/main         # 自动寄存后变基,结束时恢复
git config --global rebase.autoStash true  # 让它成为默认行为
git status                                 # 恢复后确认改动都在
git stash list                             # 中断时查看是否留有寄存条目
git rebase --abort                         # 变基出错时中止,改动随后恢复

提示信息与含义

提示含义
创建寄存条目变基开始前已把工作区改动寄存
应用寄存条目变基结束并成功恢复改动
恢复时冲突改动与重放结果冲突,需要手工处理
中止变基寄存的改动重新回到工作区或寄存列表
自动寄存的恢复发生在变基最后一步,冲突以普通工作区冲突呈现,按平时处理冲突的方式解决即可.
长时间变基期间改动一直躺在寄存区:中断后先查看寄存列表确认改动还在,再决定是否继续其他操作。
被自动寄存的改动不会出现在提交历史里,变基完成后仍属于未提交状态;如果本意是想把它们整理进提交,需要在恢复之后自己完成。

易错点

  • 中断后以为改动丢了,其实仍在寄存列表里,先查看再判断,避免重复编辑同一份内容
  • 恢复时出现冲突就直接丢弃内容,可能损失尚未提交的有效改动,应逐块确认取舍
  • 把它当成备份手段依赖,异常终止时仍会留下寄存条目需要人工清理
  • 在寄存期间切换分支做别的事,回来时忘了这层状态,改动落点容易混乱

数据来源与参考

  • Git 官方文档:git-rebase(--autostash)
  • Git 官方文档:git-config(rebase.autoStash)
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌