Git怎么LFS管理大文件_Git LFS大文件存储使用教程【进阶】

根本原因是git lfs install仅配置本地钩子，未将已跟踪的大文件重写进LFS轨道，需先git lfs track指定文件类型，再git rm --cached后重新add以转换为LFS指针。

Git LFS初始化后push还是卡在大文件上

这事儿挺常见的：明明运行了 git lfs install，怎么推送大文件时还是慢如蜗牛，甚至失败？问题根源在于，那条命令仅仅是在本地配置了必要的钩子，它并不会“魔法般”地把仓库里已经存在的大文件自动迁移到LFS的轨道上。Git依然把它们当作普通文件来跟踪，推送时自然要传输完整的文件内容，瓶颈依旧。

所以，关键得手动把这些“漏网之鱼”纳入LFS的管理体系，并重新提交。具体步骤得按顺序来：

• 首先，用 git lfs track "*.psd" 明确告诉Git哪些文件类型归LFS管（或者指定具体路径，比如 git lfs track "assets/large.zip"）。这个操作会更新 .gitattributes 文件。
• 紧接着，别忘了执行 git add .gitattributes。规则文件本身不提交，规则就不会生效。
• 接下来是关键一步：对于已经被Git跟踪的大文件，需要用 git rm --cached 把它从暂存区移除（注意，这不会删除工作区里的实际文件），然后再用 git add 重新添加。这一次，Git就会根据 .gitattributes 里的规则，将其转换为一个轻量级的LFS指针文件。
• 如果这些大文件在历史提交中已经存在了很久，涉及多次提交，那么就需要动用“历史重写”工具了：git lfs migrate import --include="*.zip"。不过得提醒一句，重写历史会影响所有协作者，操作后需要团队全员强制同步。

pull下来的是文本指针而不是真实文件

拉取代码后，发现本该是图片或模型的文件，打开却是一段奇怪的文本指针？别慌，这其实是LFS的正常工作机制。出现这种情况，通常意味着你的本地Git环境没有正确安装或启用LFS的“过滤器”（filter）。问题出在本地，而不是远程服务器，文件本身也没有损坏。

检查和修复的路径很清晰：

• 先确认本机是否安装了Git LFS：运行 git lfs version，如果没有输出，就需要先安装（macOS用户可以用 brew install git-lfs，Windows用户建议从官网下载安装包）。
• 安装后，运行 git lfs install（注意，不是init，clone操作也不会自动触发这个）。这个命令会在你的 .git/hooks/ 目录下部署必要的钩子，比如pre-push和post-checkout。
• 如果你之前克隆仓库时没有启用LFS支持，现在可以直接运行 git lfs pull 来批量下载所有LFS管理的真实文件内容。当然，也可以针对单个文件使用 git lfs checkout 。
• 额外注意：在某些持续集成（CI）环境或旧版本的Git中，可能需要显式启用过滤器，例如通过 -c filter.lfs.smudge=true 参数。

Git LFS上传失败报错"batch request failed: 401 Unauthorized"

代码推送（git push）明明成功了，但LFS文件上传却报401未授权错误？这往往不是你的仓库权限配置错了，而是凭证（token）过期了，或者没有正确地传递给LFS的服务端。Git和Git LFS使用了两套相对独立的认证流程：Git操作可能用的是SSH密钥或已缓存的密码，而LFS文件传输走的是独立的HTTP接口，需要特定的访问令牌。

常见的排查方向和解法如下：

• 对于GitHub或GitLab，确保你使用的Personal Access Token包含了必要的权限。在GitHub上，需要 read:packages 和 write:packages 权限；在GitLab上，通常需要 api 权限。仅靠账户密码或SSH密钥是不行的。
• 可以尝试运行 git lfs install --force 来强制重置凭证存储的配置，然后用 git credential reject 命令清除旧的缓存凭据（需要指定host和protocol）。
• 检查LFS的端点（endpoint）地址是否正确：运行 git config --get-regexp 'lfs.*url'。例如，GitHub的LFS端点通常是 https://github.com//.git/info/lfs，这和原始的Git仓库URL不同。
• 如果是企业自建的Git服务器，需要确认服务器端是否部署了 git-lfs-authenticate 钩子，并且该钩子能返回有效的JWT令牌。

用 git clone 拉项目时跳过LFS文件下载

有时候，我们只想快速拉取代码结构进行查看，不想等待几百MB甚至几个GB的LFS资源（如图片、模型）慢慢下载完。这能做到吗？当然可以，核心思路是暂时关闭LFS的“smudge”（涂抹）过滤器。但必须清楚后果：这样做之后，所有本应由LFS管理的文件，在本地都只会显示为文本指针，无法直接打开或使用。

有两种相对可控的方式：

• 在克隆时直接附加参数：git clone -c filter.lfs.smudge=false <仓库URL>。这样克隆下来的仓库，所有LFS文件都是指针。之后如果需要某个具体文件，再单独执行 git lfs pull --include="path/to/file.bin" 来下载。
• 全局禁用（请谨慎使用）：运行 git config --global filter.lfs.smudge false。这适合一些只读的CI构建任务，但在开发者的机器上这样设置，很容易导致误以为文件缺失。
• 需要注意一个“陷阱”：即使关闭了smudge过滤器，运行 git status 命令时，工作区仍然会显示是干净的（clean），因为Git确实管理着那些指针文件本身。要验证一个文件是否已下载了真实内容，最直接的方法是查看文件大小，或者使用 file <文件名> 命令查看文件类型。

最后，理解Git LFS有一个至关重要的点：它并没有改变Git底层的对象模型，其本质只是用一个小型文本指针文件，替换了原本巨大的二进制文件对象（blob），并将真实内容托管到独立的服务器上。因此，它的整个工作流程高度依赖于本地钩子、正确的凭证以及网络连接这三者同时就位——任何一个环节断掉，都可能让你陷入“仓库看起来一切正常，但文件实际无法使用”的尴尬状态。