这是我遇到的问题:

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

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

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

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 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"为该提交设置一个提交消息。

我有这个确切的错误与一些文件存储与git-LFS和解决它的方式一样，我已经解决了一个linending诱导borked索引。

清除缓存并进行硬复位:

git rm --cached -r .
git reset --hard

对于我来说，这比一个新鲜的克隆要快得多，因为我的repo中有巨大的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:

$

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

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