Git LFS 跳过文件，但 git 开始将其推送到存储库

Question

我的 Github 存储库中有一个大文件，我通常使用 git lfs 上传该文件。 对于较新的提交，我必须更改文件，但现在在推送时，git lfs 正在跳过该文件，而普通 git 会尝试上传它。当然，这会失败，因为它超出了 Github 的最大文件大小。 当我运行时

GIT_TRACE=1 git 推送

这是输出:

trace git-lfs: run_command: 'git' version trace git-lfs: run_command: 'git' config -l trace git-lfs: tq: running as batched queue, batch size of 100 trace git-lfs: run_command: ssh -- [email protected] git-lfs-authenticate myRepo.git upload trace git-lfs: HTTP: POST https://lfs.github.com/myRepo/locks/verify trace git-lfs: HTTP: 200 trace git-lfs: HTTP: {"ours":[],"theirs":[],"next_cursor":""}

trace git-lfs: pre-push: refs/heads/master d7b0e4138403023433894f756d63bdadfabac125 refs/heads/master 683a30586bc68758230da6686fa902d4621b358a trace git-lfs: run_command: git rev-list --objects d7b0e4138403023433894f756d63bdadfabac125 --not --remotes=origin -- trace git-lfs: run_command: git cat-file --batch trace git-lfs: tq: sending batch of size 1 trace git-lfs: ssh cache: [email protected] git-lfs-authenticate myRepo.git upload trace git-lfs: api: batch 1 files trace git-lfs: HTTP: POST https://lfs.github.com/myRepo/objects/batch trace git-lfs: HTTP: 200 trace git-lfs: HTTP: {"objects":[{"oid":"1e24fed72634c9217ce7856d11ee204d38eb154fc90572a8ef047007f2211a6c","size":246116656}]} trace git-lfs: tq: starting transfer adapter "basic" Git LFS: (0 of 0 files, 1 skipped) 0 B / 0 B, 234.72 MB skipped
17:22:37.083227 run-command.c:343 trace: run_command: 'pack-objects' '--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' '--progress' 17:22:37.084316 exec_cmd.c:128
trace: exec: 'git' 'pack-objects' '--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' '--progress' 17:22:37.088704 git.c:348 trace: built-in: git 'pack-objects' '--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' '--progress' Counting objects: 109, done. Delta compression using up to 4 threads.

Compressing objects: 100% (106/106), done. Writing objects: 100% (109/109), 73.55 MiB | 1.81 MiB/s, done. Total 109 (delta 74), reused 0 (delta 0) remote: Resolving deltas: 100% (74/74), completed with 53 local objects. remote: error: GH001: Large files detected. You may want to try Git Large File Storage - https://git-lfs.github.com. remote: error: Trace: e87aee9bcda79c0a788ae345112c9d37 remote: error: See http://git.io/iEPt8g for more information. remote: error: File src/ios/sdk/myLib.framework/Framework is 234.72 MB; this exceeds GitHub's file size limit of 100.00 MB To [email protected]:myRepo.git ! [remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to '[email protected]:myRepo.git'

Answer 1

听起来将文件的新版本添加到索引时未应用 lfs clean 过滤器。如果文件名没有更改，则可能意味着不存在将该路径与 LFS 关联的 .gitattributes 文件。 (要么从来没有一个，并且当您第一次添加文件的旧版本时，您以某种方式手动运行了干净的过滤器；或者有一个，但它没有被提交；或者它已被删除或以不再有效的方式修改匹配文件；等等...)

澄清一下 - 如果文件名确实发生了变化，它可能会更改为与 .gitattributes 文件中的任何路径都不匹配的内容。因此，您需要更新 .gitattributes 以匹配新文件名。

一旦使用 LFS 跟踪暂存文件，git 看到的(在索引和数据库中)就是 LFS 指针文件。因此，即使删除属性文件，也不会立即导致大文件上传到存储库数据库中。但是，如果您重新添加文件(修改后必须这样做)并且当时未设置属性，则整个文件将被暂存，而不是指针文件。

我认为 LFS 在上面的跟踪中跳过的是文件的旧版本 - 因为服务器已经有了它。这是正常现象。

但是你试图推送的提交是不好的；它不可撤销地嵌入了完整的文件。您需要修改(或 rebase ，或以其他方式重写)每个包含完整文件的提交。幸运的是，由于这会阻止共享提交，因此您应该能够安全地重写它们，而不必担心其他人陷入“上游 rebase ”情况。

总结一下:

确保您有一个 .gitattributes 文件，该文件将 LFS 属性分配给与大文件匹配的路径。您应该将此 .gitattributes 文件添加到索引中。

删除大文件的新版本并重新索引。

git rm --cached path/to/big/file
git add path/to/big/file

如果 .gitattributes 设置正确，add 这次将通过 LFS clean 过滤器；一个指针文件将被添加到索引中，并创建一个新的 LFS 对象。

git commit --amend

用使用 LFS 的新提交替换嵌入了大 BLOB 的提交。

现在尝试 push 。如果仍然失败，则意味着您可能需要修复其他提交，然后事情可能会变得更加复杂。