git拉取分支超时主因是历史中残留大文件，即使已删除仍需传输完整对象链；应先用git rev-list排查，再通过--depth=1浅克隆或git filter-repo清洗历史。
Git 拉取分支超时，八成不是网络问题，而是你拉的分支里混进了历史大文件——哪怕它现在已被删，git 仍会把整个对象链完整传输一遍。
git pull origin feature/x 分支超时，先查它有没有大文件残留
超时往往发生在 git pull 过程中卡在 “Resolving deltas” 或直接报 RPC failed; HTTP 504，这不是因为当前分支有大文件，而是该分支的某个历史提交曾引入过（比如 target/、dist/、node_modules/ 或 .zip 包），而 git 默认要遍历全部历史来计算差异。
- 进项目根目录，运行：
git rev-list --objects --all | grep "$(git verify-pack -v .git/objects/pack/*.idx | sort -k3 -n | tail -5 | awk '{print $1}')" | head -10，看输出里有没有可疑路径（如target/、lib/、doc/） - 如果发现是某次旧提交塞进去的，别急着删——
git reset --hard或git rm --cached都无效，它们只影响工作区和暂存区，不清理已打包的对象 - 真正要动的是 reflog 和 pack 文件，这一步必须谨慎：先备份整个
.git目录，再决定是否走git filter-repo清洗历史
只想快速拉下代码？用 --depth=1 + 指定分支绕过历史
对 CI/CD 流水线或临时调试场景，你根本不需要完整历史。只要最新快照，就别让 git 白跑几万次对象解析。
- 克隆时加
--depth=1：git clone --depth=1 -b feature/x https://gitee.com/team/repo.git - 已有仓库想“变浅”：
git fetch --unshallow不适用；正确做法是git fetch --depth=1 origin feature/x，然后git checkout -b feature/x origin/feature/x - 注意：
--depth=1后无法git log --all或git blame跨提交追溯，但日常构建、测试完全够用 - 某些老旧 Git 版本（如 2.15 以下）不支持
--depth对单分支 fetch，此时只能重新 clone
团队共用一个仓库，但有人 push 了 LFS 大文件，其他人却拉不到
这不是权限问题，是 Git LFS 客户端没启用——LFS 文件在仓库里只是文本指针，内容存在 LFS 服务器上，没装 LFS 就只能看到一堆 version https://git-lfs.github.com/spec/v1 的空壳。
- 确认远程是否启用了 LFS：
git ls-files | grep '\.gitattributes'，再看.gitattributes里有没有类似*.psd filter=lfs diff=lfs merge=lfs -text的规则 - 本地未安装 LFS：
git lfs install（全局只需一次）；若提示 command not found，说明没装 Git LFS，得去官网下对应平台二进制包 - 已安装但没生效：检查
git config --list | grep lfs，确保有filter.lfs.smudge和filter.lfs.clean条目；没有就手动补：git lfs install --force - 拉取后仍显示指针？执行
git lfs pull单独下载 LFS 对象，而不是靠git pull自动触发
运维脚本仓库里混进了 200MB 的日志压缩包，怎么救？
这类问题最典型：CI 脚本误把 archive-$(date).tar.gz 提交进 Git，导致每次 git clone 都卡死。删文件 + commit 只是掩耳盗铃，真正的体积还在对象库中。
- 第一步永远是止损：
git update-index --assume-unchanged path/to/bigfile.tar.gz，防止后续误提交 - 第二步定位源头：
git log --oneline -- path/to/bigfile.tar.gz找到首次提交 SHA，再用git show <sha>:path/to/bigfile.tar.gz | head -c 100</sha>确认确实是二进制 - 第三步清洗（仅限无人正在基于该历史开发的仓库）：
git filter-repo --path path/to/bigfile.tar.gz --invert-paths --force；注意：此操作会重写所有相关提交 SHA，所有协作者必须重新 clone - 最后一步加固：
echo "*.tar.gz filter=lfs diff=lfs merge=lfs -text" >> .gitattributes && git add .gitattributes && git commit -m "enforce LFS for archives"
真正麻烦的从来不是“怎么删”，而是“删完谁来同步新历史”。一旦用了 filter-repo，所有人的本地分支都得废弃重建——这点在自动化部署脚本里最容易被忽略。
