如果标记为已修改的暂存文件,如何清理repo
后
git reset --hard
我明白了
遇到了应该是指针的7个文件,但不是:
git clean -fdx
也没有帮助
kar*_*yon 35
从 git lfs 2.5.0 开始，有一个新命令可以使这更容易（docs）：
git lfs migrate import --no-rewrite "broken file.jpg" "another broken file.png" ...
这将“迁移”文件到 git lfs ，它应该在 lfs 中.gitattributes，但目前不是（这是您的错误消息的原因）。
--no-rewrite 防止 git 将此应用于旧提交，而是创建一个新提交。
使用-m "commitmessage"设置为犯commitmessage。
Ria*_*son 34
我对git-LFS存储的一些文件有这个确切的错误并解决了它,就像我解决了一个线性诱导的borked索引一样.
清除缓存并执行硬重置:
git rm --cached -r .
git reset --hard
这是显著比新鲜克隆我更快,因为在我的回购巨大的git-LFS文件.
Ans*_*imu 34
就像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 .
这对我有用！
Jor*_*dan 34
问题来自标记为由 git LFS 在 git LFS 跟踪的文件类型.gitattributes和一些匹配文件之间的不匹配，这些文件已经在传统的非 LFS 版本控制下。
所以这里最简单的解决方法是.gitattributes暂时删除文件：
git rm .gitattributes
git reset .
git checkout .
之后，您可以结帐任何其他分支。
还有一个建议：在向 git LFS 添加新文件类型时，不要通过修改.gitattributes而是手动执行此操作，例如通过运行：
git lfs track PATTERN
其中 PATTERN 是匹配文件的模式，例如 *.so
这样，所有与新跟踪模式匹配的非 LFS 版本化文件都将被标记为脏文件，并且可以简单地添加，即转换为 git LFS（文件指针）。
Tra*_*ter 22
这些解决方案都不适合我，但我拼凑了一些来源，最终解决了所有这些问题。
推送您不想丢失的任何更改
如果可以... 如果不能，或者如果您不关心您的更改，请按。
停止一切
SourceTree、任何服务器、文件浏览器和浏览器。有时，如果它在其他地方使用，这些东西将不起作用。如有疑问，请停止它 - 这样做最好是矫枉过正。
另外，进入任务管理器，强制退出任何bash.exe进程。Git Bash 倾向于在您关闭窗口后保持文件打开。
打开命令窗口（或终端）
cd 到您的本地仓库。
卸载 lfs
> git lfs uninstall
然后它会说：
Hooks for this repository have been removed.
Global Git LFS configuration has been removed.
重启
> git reset --hard
它可能会经历很多输出......
重新安装 lfs
> git lfs install
这可能再次说明它找到了应该是指针但不是指针的文件。没关系，继续！
拉用 lfs
> git lfs pull
希望用 lfs 拉动会覆盖那些无聊的文件。
我的一些消息来源说此时他们的回购再次工作，但不是我个人。如果需要，您可以打开 SourceTree 或其他任何内容进行检查，但如果它不起作用，您可能必须从顶部开始。
迁移
这里的核心问题是lfs，不是下载像音频、视频、图像这样的大文件——任何大于 1Mb 的文件——它只是在服务器上指向它们。如果你有一堆大文件，这很有用，你没有拉下所有的东西。所以你的本地仓库更小更灵活。但是，在我不确定的情况下，似乎有可能损坏指针。我确信这是一个 lfs 人意识到并正在努力解决的问题，但现在我们必须自己解决。
到目前为止我们所做的是
lfslfs所以现在我们的文件夹中有所有这些东西，要么是文件要么是指向文件的指针，lfs需要弄清楚是否有任何文件应该是指针，反之亦然。希望通过执行上述步骤，我们删除了损坏的指针。因此，我们将执行migrate启动通过 repo 上文件的过程，如果它们大于 1Mb，lfs 将用指针替换它们。
> git lfs migrate
更多错误
在这一点上，其他人停下来说他们又开始工作了，但我不是。我有一个错误：
git rev-list 中的错误...退出状态 128 致命：错误修订版 '...
v1.0.0'
@guneyozsan 在github 帮助页面上，将最后一块拼图发布到了拼图上，尽管它没有解决他的问题。
> git lfs migrate info --include-ref=v1.0.0
请注意，版本与出错的版本匹配 - v1.0.0。您将需要替换v1.0.0为您在错误中得到的任何版本。
我还没有找到有关为什么会发生此错误的来源，但我的猜测是migrate本地存储库上生成的 lfs 版本号与源版本不匹配。对我来说，所有这一切都是在 SourceTree 在推送过程中崩溃时开始的，我强迫机器重新启动，当发生这种情况时，lfs 不知道如何处理它，所以它只是卡在这个试图更新的循环中，但是它无法读取损坏的数据。因此需要冗长的故障排除。
藏匿和拉动
当您打开 SourceTree 时，您可能会看到它想要重新添加所有文件。不要那样做。藏起来，然后拉。
繁荣，恐怖有望结束。如果没有，这个git hub 页面或这个页面可能会帮助你更多，但这对我有用。
小智 19
跑步
git add --renormalize .
并提交这些更改。即使另一个用户在另一个分支上执行相同的操作也是安全的，因为 LFS 指针是从文件的哈希派生的。它还可能捕获一些行结尾错误的文件。
导致此错误的一个可能原因是与 git LFS 相关的更改.gitattributes影响了存储库中已添加的文件。
（我不确定重现的确切步骤，但当我触及新受 .gitattributes 影响的文件时，似乎出现了问题，该文件之前作为非 LFS 文件提交，现在应该是 LFS 文件。切换分支似乎使问题变得更加严重，或者至少在问题解决之前无法切换分支。）
在这种情况下，我使用了以下步骤来防止此错误重复发生。
git status来自Ratata Tata在如何使更改.gitattributes生效中的回答）
git rm --cached -r .
git add -A
警告：确保在步骤 2 中没有任何需要提交的内容，因为上述步骤将添加之前未进行版本控制的任何文件
git status（它应该只修改相关文件以成为 LFS 指针，即可能导致“遇到应该是指针的文件”错误的文件）并提交更改当您执行检出包含应该由LFS跟踪的文件时，可能会发生这种情况，.gitattributes但文件是以某种方式直接提交的。您很可能有另一个程序来管理您的存储库，例如git GUI或IDE。
这可能令人沮丧，因为这些文件无处不在并且阻止您进行检出。一旦您保存更改，它们就会返回！如果您陷入这种情况，快速解决方案是将这些更改提交到临时分支上，以便您可以再次签出。
要真正解决此问题，请确保已将文件作为LFS指针提交。这应该和使用一样简单git add。git lfs status提交前检查使用的工作。git lfs ls-files将显示LFS正在管理哪些文件。
git lfs status具有误导性，因为它读取的Git LFS objects to be committed是真正列出所有更改的时间。您希望被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 lfs安装了 2.5 或更高版本（在此处下载）。
检查您使用的是git lfs下载的版本（对我来说是 2.7.7）：
>git lfs version
git-lfs/2.7.2
跑：
git lfs migrate import --fixup --everything
拉你的分支并修复任何合并冲突。
在此github 评论中找到。
接受的答案对我有用，但只有当我手动键入命令时它才有效，我在每个命令之间放置睡眠，现在它作为 bash 脚本工作：
git rm --cached -r .
sleep 1
git reset --hard
sleep 1
git rm .gitattributes
sleep 1
git reset .
sleep 1
git checkout .
这只是再一次展示了GIT-LFS是什么狗屎。
如果出现以下情况，您可能会陷入这种情况：
common-base-branch但不包含在 LFS 中lfs-branch在基于 的分支中common-base-branch，文件被移动到 LFSnon-lfs-branch在另一个同样基于 的分支中common-base-branch，该文件被修改。或者：
common-base-branchlfs-branch在基于 的分支中common-base-branch，文件被添加到 LFSnon-lfs-branch在另一个基于 的分支中common-base-branch，该文件被添加（但没有添加到 LFS.在这两种情况下，当您尝试合并non-lfs-branch到时lfs-branch，您都会收到这种错误。
你可能会问为什么这首先会发生，但答案是很多软件是由多个人开发的（这就是为什么你首先拥有像 GIT 这样的版本控制系统），而人们不这样做不总是互相交谈，或者 LFS 是在项目历史的某个特性分支中稍后引入的，而“正常”开发仍在其他分支中继续进行。
这是合法的合并冲突情况，而不是错误或损坏的工作目录或任何东西（正如其他一些答案所暗示的那样）。GIT-LFS 只是处理得很差。
您现在要做的是确保冲突文件的正确版本进入 GIT-LFS，因此您可能想要选择这个问题的答案，它的作用就是......（TODO：插入至少一个链接有效的答案）
| 归档时间： |
|
| 查看次数： |
11780 次 |
| 最近记录： |