这是我的git lfs托管文件列表
$ git lfs ls-files
b1d5dd29dd - file1.zip
27d3073f43 - file2.zip
fb4e699c05 * file3.zip
为什么一个文件旁边有一个星号/星号(*),而其他文件旁边有一个短划线( - )？
git lfs wiki似乎表明(*)是预期的.
https://github.com/github/git-lfs/wiki/Tutorial
git lfs status 显示全部清除(没有任何提交/推送/暂存).
可以让 git将文件视为 binary，以避免尝试合并并避免行尾损坏等。
我试图对 git-lfs 做同样的事情，并打开 .gitattributes 文件以发现 git-lfs（已在 repo 中使用）添加了以下属性：
*.mat filter=lfs diff=lfs merge=lfs -text
上面的链接建议我添加二进制属性，相当于：
*.mat -diff -merge -text
我认为这很可能是我正在寻找的：
*.mat filter=lfs -diff -merge -text
我认为应该将文件存储在 git-lfs 端点并维护相关指针，但以与 git 处理具有 -diff -merge -text 属性的文件完全相同的方式处理它。
我通常只是尝试这个，但我担心破坏二进制文件......所以我的三部分问题是：
提前致谢！
汤姆
Bitbucket 服务器上托管了 LFS git 存储库。现在我们不需要 LFS。
如何从 git LFS 存储库迁移回普通存储库？
如果使用 LFS 进行 repo - 提交中有“指针”而不是文件。如果我需要删除 LFS - 我应该使用文件而不是“指针”。那么如何用提交历史中的文件替换所有“指针”呢？
建议，它类似于git lfs smudge但应该应用于所有日志。
我在 Git 中有一个 XML 模型（100 MB），它经常变化并且大小不断增长。我正在考虑使用 Git LFS 来处理它。
通过检查文档，我不确定 Git LFS 是否支持文件的实际合并，或者当出现冲突时，应该遵循“我们的”或“他们的”方法。
Git LFS 是否支持跟踪文件的“真实”内容的实际合并？
---- 更新 1----
我在我的电脑上安装了 Git LFS 来跟踪 .xml 文件。因此，我的 XML 模型的内容不再是 XML 内容，而是指向 Git LFS 服务器的指针。这是我的 XML 文件现在的样子。
version https://git-lfs.github.com/spec/v1
oid sha256:0e23dcebda1977c424e5d0f25fda57d6eff9c2a5bbb6df7dd4985b64cf437d20
size 53
因此，如果我在两个分支中更改此 XML 文件并尝试合并，则会引发冲突。当我打开 XML 文件解决冲突时，我需要在一个 oid 和另一个之间进行选择：
<<<<<<< HEAD
oid sha256:0e23dcebda1977c424e5d0f25fda57d6eff9c2a5bbb6df7dd4985b64cf437d20
size 53
=======
oid sha256:cbe18ff9b73fad7d5b9cdcd177f9be9cf25bc88db279f3136aed5bfdec7eb0f7
size 91554569
>>>>>>> refs/heads/LFSbr1
---- 更新 2 ---
这是我在执行“git lfs env”时得到的结果：
WARNING: Reading LFS config from ".gitconfig", not ".lfsconfig". Rename to ".lfsconfig" before Git …当我查看 lfs 文件的差异时，我只看到了 oid 和大小的差异。有没有办法轻松区分实际文件内容？
尽管我的单个剩余大文件（138 mb）现在被 LFS（Github 的大文件存储）跟踪，但我以某种方式达到了 github 数据限制。我重置为最后一次提交，确保 LFS 正在跟踪唯一（据我所知）有问题的文件。我仍然收到以下错误，不知道该怎么做。
batch response: This repository is over its data quota. Purchase more data packs to restore access.
Uploading LFS objects: 0% (0/1), 0 B | 0 B/s, done
error: failed to push some refs to <repo name>
我之前成功使用过 LFS 存储多个大文件。我不知道是什么导致了这个问题。
当我git lfs migrate info --everything在存储库上运行时，我得到以下输出：
... clipped
migrate: Examining commits: 99% (3622/3647) migrate: Examining commits: 100% (3647/3647), done
*.json 56 MB 739/739 files(s) 100%
*.py 54 MB 2382/2382 files(s) 100%
*.ps1 9.4 MB 468/468 files(s) 100%
*.stl 5.3 MB 4/4 files(s) 100%
*.js 3.4 MB 45/45 files(s) 100%
56 MB对于*.json739可能是文件的数量，什么什么的第一手段，什么第二装置？（x/y - x 是什么，y 是什么？）100% - 百分之什么？我正在使用虚幻引擎4,它将所有资产文件序列化为二进制文件.目前,项目大小小于10MB,但.git文件夹几乎是700MB.我有LFS跟踪所有资产文件并lfs migrate在回购中做了一个,但回购仍然很大.GitHub说文件在LFS中,但在推送重写的历史记录后我没有看到我的LFS存储使用率表上升.
我不确定这是否是LFS的工作方式,但据我所知,Git将在LFS中存储指向该文件的指针,并且只从HEAD所在的提交中下载该文件的版本.
我在这里很丢失.我认为值得一提的是我在git中是一个新手,所以请放轻松我.
提前致谢.
编辑:
我运行git lfs install --skip-smudge然后克隆了repo,这使得repo文件夹变得更小,因为克隆时没有下载LFS文件.问题是,现在我只有指针文件,并且git lfs pull无法检出所有文件.错误信息是Could not check out "<file-name>".
我最近将许多（新）文件添加到了git存储库中，并使用Git LFS对其进行了跟踪。我的遥控器是BitBucket，它可以按预期正常运行。
除此之外，对于我添加到LFS的每个文件，都会向我添加一个条目.git/config，如下所示：
[lfs "https://bitbucket.org/%7B%7D/%7B********-****-****-****-****6bcd1adc%7D/info/lfs/object/verify?upload_id=********-d87a-47f9-a857-ae04********"]
access = basic
（*出于安全原因，所有都是十六进制字符，我删除了）
因为我为使用LFS跟踪和推送的每个文件添加了一个条目，并且我在LFS中有数百个文件，所以我的git config文件现在很大。
我认为这个问题是在将origin遥控器（从一个BitBucket存储库切换到另一个）后开始的。
发生了什么，更重要的是，我该如何解决？
我可以安全地从中删除这些条目.git/config吗？
作为参考，这是在相同的配置文件中配置BitBucket遥控器的方式：
[remote "origin"]
url = https://user@bitbucket.org/user/repository.git
fetch = +refs/heads/*:refs/remotes/origin/*
[lfs "https://user@bitbucket.org/user/repository.git/info/lfs"]
locksverify = false
access = basic
[lfs "https://bitbucket.org/user/repository.git/info/lfs"]
access = basic
这就是仓库.gitattributes根目录中的LFS部分：
...
database/seeds/sql/content/*/allcontent.sql filter=lfs diff=lfs merge=lfs -text
public/img/*/path1/*.normal@2x.jpg filter=lfs diff=lfs merge=lfs -text
public/img/*/path2/*.normal@2x.jpg filter=lfs diff=lfs merge=lfs -text
更新 ; 我跑了git lfs uninstall，然后git lfs install --local在存储库中查看它是否可以解决任何问题，但不能解决问题（也就是说，对于我添加到LFS的新文件，更多行仍被添加到.git / …
我在客户端和服务器上的git仓库*中都缺少一堆LFS对象。我知道这些对象丢失了，没关系。不幸的是，这意味着git lfs fetch --all甚至git lfs push --all origin将失败。
我想通过使用虚拟文本文件替换二进制文件或完全删除指针来清除存储库中的“损坏的指针”。我也知道这涉及到重写历史记录，这也很好。
最好的进行方法是什么？
*为了澄清，我丢失了服务器上的一些 LFS文件，但不是全部，也不是这些文件的所有修订版。
例如，我已经在3次提交中对foo.png进行了修改：
LFS服务器不再具有foo.png版本2，因此我想从历史记录中删除该提交。不幸的是，git lfs不会告诉我哪个提交被破坏了，只是告诉我661f0797丢失了。
（记录下来，我发现了丢失的文件，所以我不再有这个问题，但是解决方案应该仍然很有趣！）