我刚遇到一个我从未见过的问题，找不到任何帮助。
我在托管环境中的实时网站上运行git master存储库，并在同一服务器上运行裸源存储库。我们所有的开发人员提交的内容都移交给了原始原始主机，该原始主机具有一个接收后挂钩，用于将每个提交推送到主存储库，以便将推送反映在实时站点文件中。唯一的烦恼是，每当我们获得WordPress更新时，我们都必须提交主存储库，然后将其推回原始存储库，以便我们的开发人员可以下载这些更新的文件。
问题：今天，我去提交WordPress插件更新，并且提交工作正常，但是该推送产生了以下神秘错误，我无法找到任何帮助：
git push origin master
Counting objects: 344, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (323/323), done.
Writing objects: 100% (344/344), 1.76 MiB | 5.61 MiB/s, done.
Total 344 (delta 237), reused 14 (delta 1)
remote: Resolving deltas: 100% (237/237), completed with 226 local objects.
remote: Running post-receive (git pull origin master):
remote: error: index uses ▒yz▒ extension, which we do not understand
remote: fatal: index file corrupt
（当我运行git diff时，字母“ yz”周围的怪异符号读为“ <B3>yz<AC>”）
如果我在主服务器上运行git status（由于它是裸仓库而无法在原点上运行），它将重复输出的最后两行。如果我在两个存储库上都运行git log，它们看起来很正常，但是原点当然是在主数据库后面的一次提交，因为对主数据库的提交起作用了，但推送到原点失败了。
我以前从未听说过这个“ yz”扩展名，据我所知，没有人也没有。我所做的只是一次提交和一次推送，而推送失败了。我们不使用任何这样的“ yz”扩展名，我们使用香草Git，执行非常基本的推拉操作，我们的接收后挂钩大约5行脚本，该脚本仅将每个提交从原点自动推送到主节点并将文件权限重置为确保Web服务器可以读取它们。我们正在做的唯一奇怪的事情是使用Git管理WordPress网站以进行版本控制。所有开发人员都可在Windows上使用TortoiseGit，而无需任何特殊设置或任何种类的插件。
我已经看到很多有关损坏索引的问题和答案，但没有这样的东西。
我还没有尝试过任何东西，因为我不确定该怎么做，不了解Git的内部原理，也不想破坏任何东西，但是我们需要能够进行推拉，并且直到仓库再次同步。
前缀为remote:的所有内容都不来自您的 Git，而是来自其 Git —您的Git调用的Git，是您运行git push时使用的URL。
是他们的Git抱怨他们的Git的索引。这可能是他们计算机上的文件损坏问题。无论“他们”是谁，您都需要让他们检查他们的系统。如果一切正常，则可能应该删除并重建其索引文件。
（（如果“他们” /“他们”确实是您，请转到所涉及的任何计算机，仔细检查它们是否有损坏或磁盘着火或其他任何情况，如果一切正常，请卸下并重建索引文件。）
好的，这就是我所做的：
由于我不想丢失对主存储库（损坏的索引）的任何更改，因为需要将更改推送到原始位置（工作索引），所以我运行以下命令：
rm .git/index
git reset --mixed
（混合为默认选项）
根据文档：
--mixed
Resets the index but not the working tree (i.e., the changed files are preserved but not marked for commit) and reports what has not been updated. This is the default action.
感谢torek和bk2204帮助您了解情况，并进行了一些谷歌搜索以找出最安全的索引重置过程，而不丢失任何已提交或工作的文件