自从git lfs 2.5.0以来，有一个新的命令可以让这变得更容易(docs):

git lfs migrate import --no-rewrite "broken file.jpg" "another broken file.png" ...

这将文件“迁移”到git lfs中，根据.gitattributes应该在lfs中，但目前没有(这就是出现错误消息的原因)。

——no-rewrite阻止git将此应用于旧的提交，而是创建一个新的提交。

使用-m "commitmessage"为该提交设置一个提交消息。

run

git add --renormalize .

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

上面的命令对我都没用，我在这里找到了答案

git status -s | cut -c 4- | xargs git update-index --assume-unchanged
rm .git/index && git reset

帮助我的是git 2.23中添加的git恢复命令，而不涉及整个repo

git restore——source=HEAD——staging——worktree——affected_files

执行该命令几次，直到所有警告消失。

就像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 .

这对我很管用!

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