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

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.

这招总是管用的!

问题来自于git LFS在.git属性中标记为要跟踪的文件类型与一些已经在传统的非LFS版本控制下的匹配文件之间的不匹配。

所以这里最简单的解决方法是暂时删除.gitattributes文件:

git rm .gitattributes
git reset .
git checkout .

之后，您可以结帐任何其他分支。

另外一个建议:当添加一个新的文件类型到git LFS时，最好不要手动修改.gitattributes，而是通过运行:

git lfs track PATTERN

其中PATTERN是匹配文件的模式，例如*.so

通过这种方式，所有匹配新的跟踪模式的非LFS版本文件将被标记为dirty，并可以简单地添加，即转换为git LFS(文件指针)。

这可能发生在您执行包含文件的签出时，这些文件本应由LFS跟踪(如.gitattributes中指定的那样)，但它们却被直接提交了。大多数情况下，您有另一个程序管理您的存储库，如git GUI或IDE。

这可能会令人沮丧，因为这些文件不知从哪里冒出来，阻止您进行签出。只要您将更改隐藏起来，它们就会返回!如果您陷入这种情况，一个快速的解决方法是在一个临时分支上提交这些更改，这样您就可以再次签出。

要真正解决这个问题，请确保将文件提交为LFS指针。这应该和使用git add一样简单。在提交之前使用git lfs状态检查你的工作。git lfs ls-files将显示lfs正在管理的文件。

git lfs状态是误导性的，因为当它真正列出所有更改时，它会读取git lfs对象以提交。您希望由LFS跟踪的文件应该读取类似于(LFS: c9e4f4a)或(Git: c9e4f4a -> LFS: c9e4f4a)的文件，而不是(Git: c9e4f4a)。

举例来说，我发现这是一个问题，当通过Xcode 9.2添加图像资产时，我添加了“CalendarChecked.png”，它会自动添加:

$ git status
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png

$ git lfs status

Git LFS objects to be committed:

    Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png (Git: c9e4f4a)

Git LFS objects not staged for commit:

    Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png (File: c9e4f4a)

$ git add Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png`
$ git lfs status

Git LFS objects to be committed:

    Empty/Empty/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png (LFS: c9e4f4a)

Git LFS objects not staged for commit:

$

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

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

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

分析

这是因为LFS没有跟踪这些文件，但是它们符合一些.gitattributes文件的描述。

例如,

服务器/ .gitattributes:

conf/** filter=lfs diff=lfs merge=lfs -text

server/conf/client.conf文件太大，被LFS跟踪 服务器/ conf /客户端。gflags是在git而不是LFS中跟踪的

然而,客户端。Gflags匹配服务器/。git会从LFS中拉出它，但是它没有LFS信息，错误就会被抛出。

解决方案

找到描述与encounter文件相匹配的.gitattributes文件，删除错误的描述或优化一些通配符匹配。

优化上面的例子， 服务器/ .gitattributes:

conf/client.conf filter=lfs diff=lfs merge=lfs -text

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

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

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