Git暂存区文件无法通过常规取消暂存命令移除的原因咨询

你之前的操作连续踩了三个Git和Shell的机制坑，导致命令执行结果和预期完全不符：

• 通配符匹配范围漏过了深层路径文件
  你前后两次使用*xml作为路径参数执行Git命令时，常用Shell（Bash/Zsh等）默认的Glob匹配规则中，*通配符不会跨路径分隔符/匹配内容，也就是说*xml只会命中当前命令执行目录下，文件名直接以xml结尾的文件，src/main/webapp/WEB-INF/stubborn.xml这种多级子目录下的文件根本不在匹配范围内，第一次批量取消暂存时完全没处理到这个文件。
• 对文件暂存状态的初始判断错误
  从最终git status的输出可以看到，这个文件在暂存区的状态是deleted，它根本不是你误加入的未跟踪文件：该文件本来就已经被Git纳入版本追踪，你本地工作区中已经提前将其删除，之前执行git add *xml时，Git自动把已追踪文件的工作区变动（也就是这次删除操作）同步到了暂存区，和其他未跟踪xml文件被加入暂存区的性质完全不同。
• 后续命令反向强化了错误的暂存状态
  你尝试的几个命令要么场景用错，要么执行顺序导致效果被抵消：
  • 单独执行git restore --staged src/main/webapp/WEB-INF/stubborn.xml本可以重置该文件的暂存状态，但后续操作直接覆盖了这个效果。
  • git reset HEAD~1属于误操作：从状态提示能看到，你本地分支本来就比远程同名分支落后1个提交，往回退1个commit后，新的HEAD节点本身就包含这个stubborn.xml文件，暂存区残留的删除标记和新HEAD对比，刚好会显示为待提交的删除变动，把异常状态保留了下来。
  • git rm --cached src/main/webapp/WEB-INF/stubborn.xml完全不符合使用场景：这个命令的原生作用就是从暂存区移除文件，同时将「删除该文件」标记为待提交变动，执行后暂存区必然会显示该文件为deleted状态，等于你主动把错误的删除状态重新写回了暂存区，覆盖了之前的重置效果。
  • 裸执行git reset（默认--mixed模式）本应将暂存区重置为HEAD的状态，但你是在执行完git reset HEAD~1之后运行的该命令，此时HEAD已经被回退到上一个版本，重置暂存区只会匹配回退后的HEAD状态，自然无法消除这个删除标记。

最后执行git restore --staged .能生效，是因为这个命令会递归遍历当前目录下所有层级的文件，不管暂存区的变动类型是新增、修改还是删除，全部强制还原为和当前HEAD一致的状态，既没有通配符漏匹配的问题，也不会额外写入删除类的变动标记，直接清掉了暂存区里残留的错误状态。

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