下面的进程将添加一个提交，将所有应该是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"

这只是再次显示什么一堆狗**** 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，因此您可能想要选择这个问题的答案…(注意事项:插入至少一个有效答案的链接)

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

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

当一个明显的错误突然出现时，我们的团队是这样做的:

Disable lfs for that specific type file (modifying .gitattributes or via SourceTree menus) The change will dissapear and you will see a change on .gitattributes instead Remove the problem: 3.1 One solution is to execute git reset --hard. Another way, discard changes. Sometimes the file will not come up again. 3.2.1 If the previous solution doesn't work, repeat 1 and 2. Then make sure that this branch you are in (A) has already commited and pushed everything except those annoying files. Then commit your change, but not push. 3.2.2: Go to another branch (B) 3.2.3: Remove that local branch (A) where you performed the commit to .gitattributes, forcing the removal even when it says there's a commit that hasn't been pushed. It will forget that commit (it can afterwards be removed via GC or whatever but it's not a big deal if the file that has the error is not huge) 3.2.4: Checkout the branch A again. It will download the previous status of the repository without the annoying files and LFS settings set up the correct way.

这招总是管用的!

与上面的@John Kugelman一样，但我把它放在一个别名中，因为我必须这么做很多次。

    
git rm --cached -r . > /dev/null && git reset --hard > /dev/null && git rm .gitattributes > /dev/null && git reset . && git checkout . > /dev/null

run

git add --renormalize .

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