git bundle list-heads my_repo.bundle 可查看 bundle 文件中包含的分支及对应最新提交 sha，如 c3a1b2c3d4e5f6 refs/heads/main，确保目标分支存在后再执行 fetch 或 checkout，避免因打包范围遗漏导致操作失败。
能直接用 git fetch 从 bundle 文件拉分支，但必须避开当前分支、不能直接 push、也不能当普通远程用——它本质是只读的“离线远程”。
bundle 文件里到底有哪些分支？先用 git bundle list-heads 看清再动手
别急着 fetch 或 checkout，先确认 bundle 里真有你要的分支。运行：
git bundle list-heads my_repo.bundle
输出类似：
c3a1b2c3d4e5f6 refs/heads/main<br>a1b2c3d4e5f6a7 refs/heads/feature/login<br>f1e2d3c4b5a6f7 refs/heads/feature/payment
这三行说明 bundle 包含三个分支头，对应各自的最新提交 SHA。如果某分支没出现在这里，git fetch 时会报 fatal: couldn't find remote ref xxx。
常见错误：误以为 bundle 是完整 clone，结果发现 feature/payment 没列出来——其实是打包时漏了参数，比如用了 git bundle create b.bundle main，只打了 main 分支。
- 要打全量分支 + tag，用
git bundle create repo.bundle --all - 只打特定分支和关联 tag，用
git bundle create repo.bundle main develop --tags - 增量打包（比如从 v1.2.0 到现在），用
git bundle create delta.bundle $(git rev-parse v1.2.0..HEAD)
本地没有的分支，用 git switch -c 直接从 bundle 创建
比如 bundle 里有 feature/payment，而你本地根本没有这个分支，最简方式是：
git switch -c feature/payment my_repo.bundle/feature/payment
这条命令做了三件事：创建新分支、设置上游为 bundle 中的该分支、检出到工作区。等价于老写法 git checkout -b feature/payment my_repo.bundle/feature/payment。
注意点：
- 不能写成
git checkout -b feature/payment my_repo.bundle——后者会尝试把整个 bundle 当作一个 commit 来检出，报错fatal: Not a valid object name my_repo.bundle - 路径写法必须是
<bundle>/</bundle>，中间斜杠不能少，也不能写成./my_repo.bundle/feature/payment（相对路径需带./才生效） - 如果 bundle 不包含该分支的全部历史（比如只打了部分提交），检出后
git log可能看不到早期提交——这是打包范围问题，不是命令写错
本地已有分支，想用 bundle 更新，得用 git fetch + git merge 分两步
假设你本地已有 feature/login，但落后 bundle 里的版本。不能直接 git pull my_repo.bundle feature/login（pull 不支持 bundle 作为 remote），正确流程是：
git fetch my_repo.bundle feature/login:refs/remotes/bundle/login<br>git merge bundle/login
第一行把 bundle 中的 feature/login 提交拉到本地 refs/remotes/bundle/login（模拟远程跟踪分支）；第二行合并进来。
关键细节：
- fetch 目标必须是
refs/remotes/*形式，否则可能覆盖本地分支指针，导致丢失未提交修改 - 如果当前在
feature/login分支上执行git fetch，会报fatal: Refusing to fetch into current branch——必须先git checkout main或其他分支再操作 - merge 前建议先
git log HEAD..bundle/login看差异，避免意外快进或冲突
git bundle verify 不只是校验完整性，更是交付前必做的安全检查
收到别人传来的 .bundle 文件，别急着 fetch。先运行：
git bundle verify my_repo.bundle
它会检查：
- 文件是否损坏（CRC 校验）
- 所有引用指向的对象是否都包含在包内（避免 fetch 时提示
error: object xxx is unavailable） - 如果 bundle 是用
--since或区间生成的，还会验证依赖提交是否完整
一旦 verify 失败，后续任何 fetch/checkout 都大概率出错，且错误信息往往不直观（比如突然卡住、log 显示空、或报 obscure 的 object not found）。尤其在跨团队交付时，这一步省不得——你没法要求对方重传一次再试。
真正容易被忽略的是：verify 成功 ≠ 分支可用。它只保证包自身结构完整，不保证里面分支的提交历史对你当前仓库“可应用”。比如对方用 git rebase 重写了历史，而你本地还保留旧提交，merge 时可能产生重复变更或冲突。这种兼容性问题，只能靠双方约定打包前不 rewrite 公共分支来规避。
