应先执行 git fetch --all 强制同步远程引用，若连接失败则用 git fetch --depth=1 origin main 试拉最新提交，再 git merge 合并；遇对象损坏需 git prune + git fsck 清理；fetch_head 异常时用 git branch -u 更新追踪分支。
git pull 卡在 “Resolving deltas” 或直接断连怎么办
网络中断后 git pull 没报错但分支看起来“少提交”，其实是对象下载不全，Git 本地索引和远程状态不一致。这时候不能直接重拉——Git 会认为“已最新”，跳过缺失对象。
- 先运行
git fetch --all，强制重新同步远程引用，比pull更底层、更可控 - 如果提示
fatal: unable to access '...': Failed to connect，说明远程连接仍不稳定，换用git fetch --depth=1 origin main先拉最新一层提交（轻量试水） - 确认 fetch 成功后，再用
git merge origin/your-branch合并，避免pull自动触发可能失败的自动合并 - 若提示
error: object XXX is corrupt，说明已有损坏对象，执行git prune+git fsck --unreachable清理后再 fetch
fetch 后发现本地分支 HEAD 指向错误提交
网络中断常导致 FETCH_HEAD 写入不完整，git pull 依赖它做合并基准，一旦出错，merge 会基于旧 commit，新提交看似“没拉下来”。
batch-git-url-replace
下载
批量替换指定目录下所有 Git 仓库的远程地址（remote URL）。 当用户需要将 Git 仓库从一个服务器迁移到另一个服务器时使用。 触发词：git remote 替换、git url 批量修改、git 仓库迁移、更换 git 地址、批量修改 remote url。
- 检查当前分支追踪关系：
git branch -vv，看是否还指向旧的origin/branchcommit hash - 手动重置追踪：运行
git branch -u origin/your-branch，强制更新 upstream 引用 - 不要用
git reset --hard origin/your-branch直接硬重置——这会丢弃本地未 push 的改动 - 如果本地有未提交修改，先
git stash，再git merge origin/your-branch，完事再git stash pop
反复失败时改用浅克隆或指定 refspec 拉取
完整历史拉取容易因单个大 blob 或深度提交链中断；尤其在 CI/CD 或低带宽环境，应绕过默认行为。
- 只拉特定提交：
git fetch origin <code>commit-hash:refs/remotes/origin/temp-branch，再git checkout temp-branch - 限制历史深度：
git fetch --depth=50 origin your-branch，适合只需最近几十次提交的场景 - 跳过 delta 解包（减少内存压力）：
git -c core.deltaBaseCacheLimit=0 fetch，对老旧 Git 版本（ - 禁用压缩传输（牺牲带宽换稳定性）：
git config --global core.compression 0，避免 zlib 解压阶段崩溃
如何验证拉取结果是否真正完整
别只看 git log 行数或最新 commit message——Git 的对象图可能缺子树、缺 blob，表面正常实则残缺。
- 运行
git cat-file -t <code>commit-hash确认关键 commit 可解析；再用git ls-tree -r <code>commit-hash检查文件列表是否合理 - 对比远程引用：
git ls-remote origin your-branch输出的 hash，和本地git rev-parse origin/your-branch是否一致 - 检查对象完整性：
git fsck --no-reflog，重点关注missing blob或broken link类错误 - 如果项目含 submodule，额外跑
git submodule update --init --recursive，网络中断常卡在这一步且不报错
