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

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.

这招总是管用的!

run

git add --renormalize .

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

导致此错误的一个可能原因是git lfs对.gitattributes的相关更改影响了repo中已经添加的文件。

(我不确定复制的确切步骤，但问题似乎发生在我接触到一个文件时，该文件最近受到.git属性的影响，该文件以前被提交为非LFS文件，现在应该是LFS文件。切换分支似乎加剧了这个问题，或者至少在问题解决之前不可能切换分支。)

在本例中，我使用下面的步骤来防止此错误重复发生。

通过遵循这里的其他答案之一来修复您所在分支的问题(例如，清除缓存和重置。我发现BheeMa的答案很有效。) 转到你的主分支，确保git状态下没有什么要提交的 强制git重新检查并“重新应用”git属性更改

从Ratata Tata的回答如何改变。gitattributes生效)

 git rm --cached -r .
 git add -A

警告:确保在第2步中没有任何东西要提交，因为上面的步骤将添加以前没有版本的任何文件

Verify the results with git status (it should only have modified relevant files to become LFS pointers, i.e. files that can potentially cause the "encountered files that should have been pointers" error) and commit changes (Optionally, merge/rebase this fix to all other branches if possible. Otherwise, this error could pop up again when switching to those branches. Note that it may be necessary to repeat the initial fix for each branch as per step 1 to be safe, though it could be ok just to commit the affected files.)

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

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

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

在我的例子中，它是一个lfs规则下的文件(我假设它是在没有安装lfs或其他东西的情况下检入的)。

所以我在.gitattributes文件中找到了它的扩展名，并将这一行注释为

#*.7z filter=lfs diff=lfs merge=lfs -text

保存这个.git属性，然后git状态显示没有问题。

之后，我取消了这一行的注释(删除了#)，保存了.gitattributes和git状态仍然显示没有问题。