被「浅克隆」催眠的一夜：为什么 Git 推不进全新的 GitHub 仓库？ • Chao's Dev & Life

在配置新项目的过程中，建了一个全新的 GitHub 空仓库，打算把本地初始化好的项目代码推上去。

配置好远程源后，执行推送：

git remote set-url origin https://github.com/<your-username>/<your-repo>.git
git branch -M main
git push -u origin main

bash

原本以为几秒钟就能搞定，终端在打包上传完成后，却抛出了一长串报错：

Enumerating objects: 471, done.
Counting objects: 100% (471/471), done.
Delta compression using up to 14 threads
Compressing objects: 100% (356/356), done.
Writing objects: 100% (471/471), 6.05 MiB | 387.03 MiB/s, done.
Total 471 (delta 81), reused 468 (delta 81), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (81/81), done.
remote: fatal: did not receive expected object 2b9c29322a27e1395f743336aefcbf95d188c846
error: remote unpack failed: index-pack failed
To https://github.com/<your-username>/<your-repo>.git
 ! [remote rejected] main -> main (failed)
error: failed to push some refs to 'https://github.com/<your-username>/<your-repo>.git'

text

代码确实传上去了（6.05 MiB 都已经写完，Delta 也解压了 100%），但远端在最后一步解包校验时，直接给拒了。

第一步：排查常见环境问题#

遇到 push 报错，习惯性的排查路径通常是这几样：

凭据与权限：GitHub Personal Access Token 是否过期？SSH Key 是否有效？（用 ssh -T git@github.com 测试正常，账号也是仓库的 Owner）。
网络与代理：上传大文件时是否发生了连接重置？（换了直连和代理，报错完全一致，且每次都精准卡在 remote: fatal: did not receive expected object 这一步）。
远程分支保护：空仓库并没有设置任何 Branch Protection 规则。

排除掉外围环境因素后，焦点回到了报错信息本身：

remote: fatal: did not receive expected object 2b9c2932...
error: remote unpack failed: index-pack failed

text

远端在执行 index-pack 时，提示缺少了一个特定的 Object（哈希为 2b9c...）。这个对象到底是什么？

在本地执行：

git rev-parse --verify 2b9c29322a27e1395f743336aefcbf95d188c846

bash

发现本地根本查不到这个哈希的实体对象。

这时候我想起这个项目的起步方式：最初拉取模板时，为了省流量和时间，顺手加了 --depth=1。

浅克隆的本质：被截断的有向无环图（DAG）#

Git 本质上是由一个个不可变的哈希对象（Blob, Tree, Commit）构成的有向无环图。

正常情况下，每一个提交（Commit）在计算自己的哈希时，都会包含它的父提交哈希（Parent Commit SHA-1）。这样从任意一个最新分支的 HEAD 节点往回追溯，都能够形成一条完整闭合的因果链。

当你执行浅克隆时：

git clone --depth=1 <template-repo>

bash

Git 为了让你只下载一层提交，做了一个折中的妥协：它在本地的 .git/ 目录下生成了一个名为 shallow 的纯文本文件：

cat .git/shallow
# 输出即为截断点的 commit hash:
# 2b9c29322a27e1395f743336aefcbf95d188c846

bash

这个文件的作用就像是给本地 Git 戴了一副眼罩——它明确告诉本地引擎：“只要遍历到这个哈希，就不要再往前追溯父提交了”。

因此，本地的 git log、git status 和 git commit 都可以在历史缺失的情况下正常工作。

为什么推送到空仓库会触发 index-pack failed？#

本地相安无事，是因为 .git/shallow 的存在抑制了完整性检查。但推送到一个全新空仓库时，情况就完全变了：

本地 Git 将变更对象打包生成 Packfile，发送给 GitHub 的 git-receive-pack 服务。
远端服务器收到数据包后，会启动 git index-pack 对接收到的包进行索引重构和图连通性验证。
在重构过程中，远端发现某个提交的父节点指向了 2b9c2932...（或者某个 Delta 压缩对象依赖了这个基底）。
由于这是一个全新的空仓库，远端数据库里一片空白；而本地在打包时，又因为浅克隆没有把这个父对象打进包里。
远端校验失败，直接抛出 fatal: did not receive expected object 2b9c...，并拒绝接纳此次推送。

简而言之：浅克隆的提交引用了一个它自己并未包含、远端也未曾拥有的历史对象，导致对象图出现了断链。

解决办法：补齐提交历史（Unshallow）#

既然知道了是因为缺少父级历史对象导致的断链，解决办法也很直接：把仓库的历史链条补全，解除浅克隆状态。

将 remote 切回原始的模板源，或者指定源拉取完整历史：

git fetch --unshallow origin

bash

（注：如果当前 remote 已经改成了新的空仓库，可以先将 remote 改回源仓库拉取，或者通过 git remote add upstream <原始源> 后执行 git fetch --unshallow upstream。）

执行成功后，本地的 .git/shallow 文件会被自动移除，祖先节点全部补齐。

此时再推送到新的 GitHub 仓库：

git remote set-url origin https://github.com/<your-username>/<your-repo>.git
git push -u origin main

bash

此时 git index-pack 验证完整通过，代码成功推送完毕。

总结#

--depth=1 适合只读消费：在 CI/CD 流水线构建、Docker 打包镜像等一次性场景下，浅克隆能显著减少拉取耗时；
作为二次开发底座时需留意：如果打算基于某个浅克隆模板长期开发并迁移到全新的远程仓库，在推送前先确认历史完整性，避免因断链导致 index-pack failed；
关注报错中的具体对象：当遇到 fatal: did not receive expected object 时，往往意味着对象图缺少了依赖基底，检查 .git/shallow 是最快的排查切入点。