如果标记为已修改的暂存文件，如何清理repo
后
git reset --hard
我明白了
遇到了应该是指针的7个文件，但不是：
git clean -fdx
也没有帮助
我对git-LFS和solved it the same way I've solved a linending induced borked index 存储的一些文件有这个确切的错误。
清除缓存并执行硬重置：
git rm --cached -r .
git reset --hard
由于我的仓库中存在巨大的git-LFS文件，因此这对我来说明显快于新鲜克隆。
像Travis Heeter在他的回答中提到的那样，尝试以下命令序列：
git lfs uninstall
git reset --hard
git lfs install
git lfs pull
如果这不起作用（因为这对我不起作用），以下黑客可能有效：
请尝试以下命令：
git rm --cached -r .
git reset --hard
git rm .gitattributes
git reset .
git checkout .
这对我有用！
当您执行包含应该由.gitattributes中指定的LFS跟踪的文件的结帐时，可能会发生这种情况，但不知何故，它们已被直接提交。很可能你有另一个程序来管理你的存储库，比如git GUI或IDE。
这可能令人沮丧，因为这些文件无处不在，并阻止您进行结帐。一旦你收起你的更改，他们就会回来！如果您遇到这种情况，快速解决方法是在临时分支上提交这些更改，以便您可以再次签出。
要真正解决此问题，请确保已将文件作为LFS指针提交。这应该像使用git add一样简单。在提交之前使用git lfs status检查您的工作。 git lfs ls-files将显示LFS正在管理的文件。
git lfs status具有误导性，因为当它真正列出所有变化时它会读取Git LFS objects to be committed。您期望由LFS跟踪的文件应该读取类似(LFS: c9e4f4a)或(Git: c9e4f4a -> LFS: c9e4f4a)而不是(Git: c9e4f4a)的内容。
举例来说，我发现这是一个问题，当通过Xcode 9.2添加图像资源时，我添加了自动添加的“CalendarChecked.png”。
$ git status
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png
$ git lfs status
Git LFS objects to be committed:
Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png (Git: c9e4f4a)
Git LFS objects not staged for commit:
Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png (File: c9e4f4a)
$ git add Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png`
$ git lfs status
Git LFS objects to be committed:
Empty/Empty/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png (LFS: c9e4f4a)
Git LFS objects not staged for commit:
$
这些解决方案都不适合我，但我拼凑了几个来源，最终解决了所有这些问题。
cmd或命令窗口。如果您不确定，请单击Windows键，然后键入cmd。它会建议命令提示符，单击它。
cd到你的回购。lfs
> git lfs uninstall
然后它会说：
Hooks for this repository have been removed.
Global Git LFS configuration has been removed.> git reset --hard
它会经历很多输出......lfs
> git lfs install
这可能再说它发现应该是指针但不是指针的文件。那没关系，继续吧！lfs拉
> git lfs pull
希望用lfs拉动将覆盖被borked的文件。
我的一些消息来源说，此时他们的回购再次运作，但不是我本人。您可以打开SourceTree来检查是否需要，但如果它不起作用，您可能必须从顶部开始。lfs通过用指针替换它们来跟踪大文件。如果您是程序员，这类似于变量指向内存中的某个位置，而不是保持实际值。
到目前为止我们所做的是
卸载lfs
删除一切
重新安装lfs
拉一切
所以现在我们在文件夹中有所有这些东西，无论是文件还是文件指针，lfs需要弄清楚是否有任何文件应该是指针而反之亦然（这里是我们可怕错误的来源 - 有些文件应该是指针，但不是）。因此，我们将执行migrate来启动通过repo上的文件的过程，如果它们大于1Mb，则lfs将用指针替换它们。
git lfs migratev1.0.0'
有一个悲剧英雄@guneyozsan在一个github help page上，尽管它没有解决他的问题，但最后一篇文章已经发布了。他在我开始寻找第一个如何解决这个问题的时间之前大约2个小时发布了它，即使这个问题已经存在了2年。祝福你@guneyozsan，祝你好运解决问题。
> git lfs migrate info --include-ref=v1.0.0
请注意，该版本与错误的版本匹配 - v1.0.0。
我没有找到关于为什么会出现此错误的消息来源，但我的猜测是migrate在本地存储库上生成的lfs版本号与源版本不匹配。无论出于何种原因，本地lfs数据被搞砸了（对我来说，所有这一切都是在SourceTree在推送过程中崩溃并且我强制重启机器时可能已经损坏了lfs数据），当发生这种情况时，SourceTree不会知道如何处理它，所以它只是陷入它试图更新的循环中，但它无法读取损坏的数据。因此冗长的故障排除。确保安装了git lfs 2.5或更高版本（download here）。
检查您使用的是您下载的git lfs版本（2.7.7对我来说）：
>git lfs version
git-lfs/2.7.2
跑：
git lfs migrate import --fixup --everything
拉你的分支并修复任何合并冲突。
发现在这个github comment。
当这显然是一个无处不在的错误时，这就是我们在团队中所做的事情：
这总是有效的！