GitHub 对普通 Git 文件给出 50 MiB 警告、100 MiB 拦截的界限；如果仓库里有超过普通仓库适用范围的素材，应先确认托管平台规则，再决定是否纳入 Git LFS。GitHub 文件大小限制说明

症状：代码能克隆，但模型、素材或二进制文件没有出现在工作目录里。
最快解法：Git LFS 可以在远程 Mac 上管理大型版本文件，但不能只执行一次 git lfs pull 就宣布环境就绪；按仓库初始化、凭据验证、按需拉取、磁盘监控、租期迁移五步配置，并在出发前用真实项目演练一次拉取与恢复。

谁该看：需要在旅途中维护模型、设计素材或二进制依赖的独立开发者。
希望用 iPad 或轻薄本连接远程 Mac、继续处理大型项目的远程设计与开发人员。
需要跨城工作，并确保临时设备接管后项目仍可打开和交付的技术自由职业者。

先判断仓库问题：Git LFS 解决什么，不解决什么

Git LFS 将大型文件的实际内容放在 LFS 服务端，Git 仓库保存指向内容的指针；因此它解决的是大型版本文件如何跟踪与协作，不是把项目变成完整备份。

先按文件的用途分类，再决定是否追踪：

  • 模型、设计素材和音视频源文件：如果需要和代码一起版本管理，且团队需要明确版本对应关系，通常适合评估 Git LFS。
  • 二进制依赖或构建产物：只有在确实需要随提交版本回溯时才考虑纳入；每次构建都会生成、可从源代码重新生成的文件，优先检查能否从仓库排除。
  • 仓库整体很大：先查看 .git 历史、分支和提交结构。Git LFS 不会自动缩小已存在的普通 Git 历史；已经提交进去的大文件，可能还要评估迁移历史的影响。
  • 单个文件触及托管限制：核对平台对普通 Git 文件、单个 LFS 对象和存储配额的规则。以 GitHub 为例，其不同方案的 LFS 单文件上限不同，超过平台上限的对象会被拒绝；不能把某个平台的限制直接套到其他托管服务。GitHub 的 LFS 文件限制

编辑判断：若大型文件需要版本对应且团队持续协作，Git LFS 适配度较高；若只是交付一次的压缩包或可再生构建产物，适配度偏低。若主要难题是远程桌面操作不顺，先处理连接方式，而不是增加仓库下载量；可以对照远程 Mac 的 VNC 连接说明检查客户端和连接流程。

仓库已经包含大文件，直接加规则就够了吗？

不一定。git lfs track 会在 .gitattributes 中添加匹配规则，但对已存在的文件，光加规则不等于把历史中的 Git 对象迁成 LFS 对象。现有文件的跟踪转换需要重新规范化并提交；要改写历史，则是另一项需要协调提交者的迁移操作。Git LFS 跟踪规则说明

因此，先在测试分支验证文件匹配和提交结果，再把规则合并到正式分支。别在旅行途中临时改正式仓库的追踪规则：同伴若没有安装 Git LFS，克隆时可能拿到指针而非实际文件。

Git LFS 远程 Mac 配置的五步流程

以下顺序把“能登录代码仓库”和“能读取 LFS 对象”分开验证。准备工作时先确认 Mac 上可调用 Git 与 Git LFS，再进入项目目录；安装方式应依据 Git LFS 官方安装说明和当前系统可用方式选择，不要把某个包管理器命令当成所有 Mac 都适用的固定步骤。Git LFS 安装与初始化文档

第一步：检查项目规则，不先改正式仓库

在项目目录查看当前分支、工作区改动和追踪规则：

git status --short
git branch --show-current
git lfs track

确认 .gitattributes 已纳入版本控制，并检查规则是否覆盖真正要管理的文件类型。若准备新增规则，先切测试分支，使用具体文件名或明确的路径模式试验；模式过宽会把不需要的产物也纳入 LFS，过窄则会漏掉项目素材。git lfs track 的匹配规则写入 .gitattributes，并遵循 Git 忽略规则的通配语义。

第二步：初始化客户端，再验证对象认证

git lfs install
git lfs env
git remote -v

git lfs install 设置 Git LFS 所需的过滤器与钩子；git lfs env 可帮助你查看 LFS 端点。认证至少要分清三件事：代码远端是否可访问、LFS 端点是否可访问、远程 Mac 登录凭据是否安全。普通 git ls-remote 或成功克隆，只能说明部分链路正常，不足以证明受限 LFS 对象也能下载。Git LFS 服务发现文档

避免把令牌直接写进远端 URL 或仓库配置。优先使用托管平台支持的凭据助手或 SSH 认证方式；若用访问令牌，按最小权限原则配置，并检查保存位置、有效期限与撤销方法。Git LFS 会使用 Git 凭据机制或服务端提供的认证信息访问 LFS API，但具体方式取决于远端和服务端实现。Git LFS 认证说明

⚠️ 如果代码克隆成功、LFS 下载却报认证错误，先检查 git lfs env 显示的端点和凭据助手，再判断是代码仓库权限、LFS 权限还是令牌过期。不要在日志、聊天记录或仓库中粘贴令牌；分享日志前也要清除认证头和私人仓库路径。

第三步：根据任务选择完整或按需下载

远程 Mac 空间充足、接下来要离线处理完整项目时，可以拉取当前分支需要的 LFS 文件：

git lfs pull

若项目素材分散、当前只处理特定目录，可以按路径筛选：

git lfs fetch --include="Assets/Models/**"
git lfs checkout

这里有个容易误判的区别：git lfs fetch 下载对象到本地存储，但不更新工作树；git lfs pull 则结合 fetch 和 checkout，让当前工作树中的匹配文件得到实际内容。路径筛选适合减少不相关下载，但应在运行真实应用前确认依赖目录没有被排除。Git LFS fetch 的 include/exclude 规则

第四步：弱网时按错误类型恢复，不猜测已完成

酒店、咖啡馆或机场网络中断时，先记录失败的命令、当前分支、错误文本和 git lfs env 中的端点；检查网络、认证和剩余磁盘空间后，再对同一分支重新执行拉取。不要把命令中断位置理解成已完成的文件边界，也不要仅凭退出成功就认定所有文件完整。Git LFS 提供 git lfs logs last 查看最近错误日志；对外分享日志前应先脱敏。

恢复后执行：

git lfs fsck
git lfs ls-files

再用项目实际依赖的设计软件、构建工具或资源加载流程打开目标文件。git lfs fsck 会检查当前提交相关对象的一致性；它不能代替应用层验证，因此最终还要确认真实项目能读到文件内容。Git LFS fsck 文档

第五步：记录磁盘来源，再清理缓存

不要只看工作目录大小。至少分别检查项目工作树、Git 历史、.git/lfs/objects 缓存、导出文件和临时素材区；同一份 LFS 内容可能同时体现为工作树文件和本地缓存对象，因此实际占用应以远程 Mac 的磁盘测量为准，不能拿一个通用容量数字代替。

清理前先确认文件已推送、未提交改动已保存、其他工作树没有依赖待清理对象。之后可先预览：

git lfs prune --dry-run

核对清理列表后再决定是否执行清理。Git LFS 的 prune 文档说明，它会依据当前检出、存储引用和其他保留条件处理本地对象；如果多个仓库共用自定义存储目录，还要格外谨慎。Git LFS prune 文档

拉取范围、凭据与存储的选择条件

不需要每次都把所有分支和素材完整下载。按任务选择，避免“省空间”与“项目打不开”之间来回试错：

  • 若出发后可能断网，且本次交付依赖多个素材目录：先用目标分支完整拉取，再做文件完整性检查与应用打开测试；否则，缺失素材会在离线时才暴露。
  • 若只处理明确的文件类别，且项目依赖边界清楚：用 include/exclude 限定下载范围，同时记录被排除的目录；否则，按需策略可能漏掉运行时才读取的素材。
  • 若仓库体积主要来自普通 Git 历史，而不是 LFS 对象：先评估浅克隆或 Git 部分克隆是否适用。Git 的 --filter=blob:none 可延后获取部分 Git 文件内容，但它不是 Git LFS 的替代品，也不代表所有工具链都适合这种克隆方式。Git clone 部分克隆说明
  • 若跨设备频繁接管，且要保留多个分支素材：不要只依赖远程 Mac 的缓存；把代码提交、未提交改动和需要恢复的 LFS 对象分别纳入交接清单，并另行确认备份策略。

旅行中管理大型代码仓库，关键不是一味追求“全拉下来”或“只拉一点”，而是让每次下载范围都能对应到当前任务。你还可以先检查远程 Mac 的存储与服务说明，再决定长期项目是否适合放到远端环境。

项目结束后的迁移和清理

租期结束、切换另一台 Mac，或临时借用其他设备接手时，先把工作区状态写清楚：

  • 代码：当前分支、未提交改动、未推送提交和子模块状态。
  • LFS：.gitattributes 是否已提交、目标分支需要哪些对象、接手设备是否已初始化 Git LFS。
  • 本地资料：未跟踪文件、忽略文件、导出结果、项目配置与所需环境变量。不要把凭据或密钥误放入仓库。
  • 验收：新设备能否访问代码和 LFS 端点、能否拉取真实文件、git lfs fsck 是否通过、应用或构建是否能读取项目资源。

如果只是换 Mac，优先在新设备克隆并按项目需要拉取，再完成验收；不要把旧设备上的 .git/lfs 缓存当成唯一副本。若准备使用 git lfs migrate 改写既有历史，应先与所有协作者确认，因为迁移可能改变历史引用和后续同步方式，不能当作普通清理命令临时执行。

离开远程 Mac 前，先确认工作已经推送或安全转移，再删除令牌、私钥等登录凭据，并检查临时导出目录。清缓存不等于归档项目，删掉本地对象前也要确认远端对象与其他备份可用。

如需持续使用 Git LFS，但不想携带 MacBook，SSHMac 的远程 Mac 租赁可以作为临时或阶段性工作环境；它不适合必须依赖本地物理接口、长期高强度占用或无法接受网络中断的任务。先按租赁方案说明确认远程连接与工作方式，再把已完成拉取、恢复和迁移演练的项目放上去。这样选型依据是你真实验证过的仓库、权限与交接流程，而不是一次成功的 git lfs pull。