下面的进程将添加一个提交，将所有应该是lfs指针的二进制文件替换为lfs指针。

Clean working copy completely. Together with the force add below this prevents any files getting added or removed due to .gitignore patterns. git clean -dfx git reset --hard git checkout -- . Add remove for everything to staging area. Working copy will not be touched. git rm --cached -r . Readd all files from working copy again. This will basically undo the previous command but will reevaluate lfs filters. Use -f to ignore .gitignore. All files present were previously checked in and should get added again. git add -f . You staging area now should only contain the binary files that previously raised the 'should have been pointers' error. git commit -m "moved files to 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 .

这对我很管用!

这些解决方案都不适合我，但我拼凑了一些资源，最终解决了所有这些问题。

Push any changes you don't want to lose If you can... If not, or if you don't care about your changes, press on. Stop Everything SourceTree, any servers, file explorers and browsers. Sometimes this stuff won't work if it's being used somewhere else. When in doubt, stop it - with this it's better to overkill. Also, go into Task Manager, force quit any bash.exe processes. Git Bash tends to hold files open after you close the window. Open a Command Window (or Terminal) cd to your local repo. Uninstall lfs > git lfs uninstall Then it'll say something like: Hooks for this repository have been removed. Global Git LFS configuration has been removed. Reset > git reset --hard It'll go through a lot of output probably... Reinstall lfs > git lfs install This may again say it found files that should have been pointers but weren't. That's OK, keep going! Pull with lfs > git lfs pull Hopefully pulling with lfs will overwrite the files that got borked. A few of my sources said at this point their repo was working again, but not me personally. You can open SourceTree or whatever to check if you want, but you may have to start from the top if it didn't work. Migrate The core issue here is that lfs, instead of downloading large files like audio, video, images - anything larger than 1Mb - it just points to them on a server. This is useful if you have a bunch of large files, you're not pulling down all that stuff. So your local repo is smaller and nimbler. However, through circumstances I'm not sure about, it seems possible to corrupt the pointers. I'm sure this is an issue that the lfs people are aware of and are working on, but for now we have to work it out ourselves. What we've done so far is uninstall lfs delete everything reinstall lfs pull everything So now we have all these things in our folder that are either files or pointers to files, and lfs needs to figure out if any files should be pointers and vise versa. And hopefully by performing the steps above we deleted the corrupted pointers. So we're going to perform migrate to kick off the procedure that goes through the files on the repo, and if they're greater than 1Mb, lfs is going to replace them with a pointer. > git lfs migrate More Errors Here's a point at which others have stopped and said they were working again, but not me. I got an error: Error in git rev-list... exit status 128 fatal: bad revision '...v1.0.0' @guneyozsan over at a github help page, posted this final piece to the puzzle, even though it didn't fix his issue. > git lfs migrate info --include-ref=v1.0.0 Notice the version matches the version that errored - v1.0.0. You will need to replace v1.0.0 with whatever version you got in your error. I haven't found a source on why this error occurs but my guess is that the lfs version number generated by migrate on your local repo doesn't match the source version. For me, all this started when SourceTree crashed during a push and I forced a machine reboot, and when that happens, lfs doesn't know how to deal with it, so it just gets stuck in this loop where it's trying to update, but it can't read the corrupted data. Hence the lengthy troubleshooting. Stash and Pull

当您打开SourceTree时，您可能会看到它想要将您的所有文件添加回来。不要那样做。藏起来，然后拉出来。

然后，恐怖事件有望结束。如果没有，这个git集线器页面或这个可能会帮助你更多，但这对我来说是有效的。

在这个问题上有多个步骤来解决。

如果你只是处于一个破碎的状态，就像卡在一个分支上，因为你不能重置/丢弃对问题文件的更改:删除.gitattributes文件可能足以让你进行下一次git移动。一旦你移动了你的git，你可能需要恢复.gitattributes文件，但至少你摆脱了困境。

我希望我在尝试上述所有方法之前就知道这一点。至少尝试一下是一个低风险的选择。

我有这个确切的错误与一些文件存储与git-LFS和解决它的方式一样，我已经解决了一个linending诱导borked索引。

清除缓存并进行硬复位:

git rm --cached -r .
git reset --hard

对于我来说，这比一个新鲜的克隆要快得多，因为我的repo中有巨大的git-LFS文件。

如果你只是想摆脱那个糟糕的承诺，你可以回到master by

git reset --soft origin/master
git reset --hard

然后你从讨厌的7非lfs文件中解脱出来:-)