如何防止Git在提交未成功完成时完全清空工作文件内容

核心诱因排查 #

• 首先可以排除git-auto-fetch插件的直接影响：该插件的基础逻辑是定时触发git fetch拉取远端元数据，本身不会触碰本地工作区的未提交修改，更不会主动清空文件内容。重点排查方向集中在日常使用的Git提交链路上：
  • 检查配置的zsh git别名、Git钩子逻辑，是否在git commit执行失败时，绑定了自动回滚类操作——比如自动触发git checkout -- .、git reset --hard这类无差别覆盖工作区文件的命令。这类操作会直接用暂存区、HEAD分支的版本完全替换当前工作区文件，如果编辑的内容还没进入暂存区，就会被直接覆盖；如果碰上Git索引损坏的极端场景，甚至会直接把文件截断为0字节。
  • 排查是否在提交链路中集成了自动变基、自动冲突解决逻辑：commit失败触发自动变基时，遇到解析异常的脚本如果对冲突文件执行截断写入操作，就会出现“文件实体存在但内容为0字节”的典型特征。
• 关于遇到的undo-tree失效、git stash无记录的原因：
  • 如果外部进程直接覆盖或截断了Emacs打开的文件，Emacs的自动文件监控会触发静默缓冲区刷新，把内存缓冲区内容替换为磁盘上的空文件，这个操作会直接重置undo-tree的内存历史，自然找不到之前的修改记录。
  • 因为修改内容从头到尾没有进入Git的暂存索引区，就算触发了自动stash逻辑，也不会被记录到stash列表里。

可落地的防护措施 #

Git流程侧加固 #

• 执行git config --global clean.requireForce true，强制要求所有git clean操作必须带--force参数才能执行，杜绝脚本误触发清理操作清空文件。
• 逐个检查.git/hooks/目录下的可执行脚本、zsh环境里的Git相关别名，把所有会在commit失败时自动执行reset --hard、checkout -- .、clean -fd的逻辑全部禁用，避免失败流程连带覆盖工作区。
• 关闭git-auto-fetch的自动清理参数，执行git config --global fetch.prune false，避免fetch时的分支清理逻辑扩散到工作区文件。

编辑器侧加固 #

• 在Emacs配置中开启自动备份机制，设置backup-by-copying t、version-control t参数：所有打开编辑的文件会自动在同目录生成带版本号的备份文件（比如lib.py.~1~、lib.py.~2~），就算原文件被外部进程清空，也可以从备份里找回历史内容。
• 开启undo-tree的自动落盘存储，调整存储频率为每30秒一次，避免内存中的撤销历史因为缓冲区刷新丢失。
• 配置auto-revert-avoid-pulling参数，当检测到外部进程把磁盘文件内容修改为0字节时，不要静默自动刷新缓冲区，先弹出确认提示，避免未保存的修改被直接覆盖。

内容的提问来源于stack exchange，提问作者alper