这里有一个修饰，不需要重新安装lfs钩子或模糊任何.gitattributes文件:

git -c filter.lfs.smudge= -c filter.lfs.clean= reset --hard

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

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集线器页面或这个可能会帮助你更多，但这对我来说是有效的。

这是我遇到的问题:

假设您创建了一个分支，并以某种方式将文件提交为非lfs。因此，您试图通过稍后在同一分支上提交文件的LFS版本来纠正它。然而，现在你不能重基或压缩，因为你会一直遇到这种“文件应该是指针，但不是”错误在重基中间。

解决使用git重置——软:https://stackoverflow.com/a/5201642/2516916

run

git add --renormalize .

并提交这些更改。即使当另一个用户在另一个分支上做同样的事情时，这样做也是安全的，因为LFS指针是从文件的散列派生的。它还可能捕获一些行尾错误的文件。

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

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

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

这只是再次显示什么一堆狗**** GIT-LFS。

你可能会遇到这种情况，如果:

文件包含在common-base-branch中，而不是LFS中 在基于common-base-branch的分支LFS -branch中，文件被移动到LFS 在另一个同样基于common-base-branch的非lfs-branch分支中，修改了文件。

或者:

文件不包含在common-base-branch中 在基于common-base-branch的分支LFS -branch中，文件被添加到LFS 在另一个同样基于common-base-branch的非LFS -branch分支中，文件被添加(但不是添加到LFS。

在这两种情况下，当您尝试将非lfs-branch合并到lfs-branch时，都会得到这种错误。

您可能会问，为什么会出现这种情况，但答案是，许多软件是由不止一个人开发的(这就是为什么会有像GIT这样的版本控制系统)，而且人们并不总是彼此交谈，或者LFS是后来在一个特性分支的项目历史中引入的，而“正常”的开发仍然在其他分支中进行。

这是一种合法的合并冲突情况，而不是错误或损坏的工作目录或任何东西(正如其他一些答案所暗示的那样)。GIT-LFS只是处理得不好。

您现在要做的是确保冲突文件的正确版本进入GIT-LFS，因此您可能想要选择这个问题的答案…(注意事项:插入至少一个有效答案的链接)