最可靠方式是用git clone --bare或git bundle create --all：前者适合长期归档，后者适合离线迁移；二者均完整包含所有分支、tag及引用，而直接复制.git或整个目录易漏reflog、notes等且无法校验完整性。

直接备份本地 Git 仓库，最可靠的方式不是复制整个项目文件夹，而是用 git clone --bare 或 git bundle create --all —— 前者适合长期归档，后者适合离线迁移或临时打包。

用 git clone --bare 创建裸仓库备份

裸仓库不含工作目录，只保留 Git 元数据（.git 内容），体积小、结构干净、可直接作为远程源使用。

• 必须在**目标备份路径外**执行，例如：git clone --bare /path/to/your/repo /backup/repo.git
• 如果原仓库有未提交的修改（即工作区脏），这些内容不会被包含——--bare 只克隆已提交历史
• 恢复时用 git clone /backup/repo.git 即可获得完整可操作仓库，含所有分支和 tag
• 不建议用 cp -r .git /backup/ 替代：它漏掉 reflog、notes、replace refs 等隐式引用，且无法校验完整性

用 git bundle create 打包成单文件

适合跨网络受限环境（如内网机器导出）、U 盘携带、或需要原子性备份的场景，但它是“快照”而非“镜像”，行为更脆弱。

Github Stars Analyzer

抓取指定 GitHub用户的 Stars 项目，生成标准化中文 Markdown 报告。用户提及「分析 GitHub stars」「导出收藏项目」「汇总 GitHub 星标」「生成 stars 报告」或粘贴含 ?tab=stars 的链接时触发。执行通过 bash...

下载

• 必须加 --all，否则默认只打包 HEAD 分支：git bundle create repo.bundle --all
• 若仓库含 refs/notes/ 或自定义 ref（如 refs/pull/），需显式列出：git bundle create repo.bundle --all refs/notes/**
• 打包前运行 git gc 能减小 bundle 体积，避免冗余对象膨胀
• 验证 bundle 是否可用，不能只看文件是否存在，要立刻执行：git bundle verify repo.bundle + git ls-remote repo.bundle

为什么不用 cp -r 或直接拷贝 .git 目录

看似最简单，实则最容易出问题：

• cp -r 整个项目目录会把未跟踪文件、构建产物、临时文件一并复制，体积大且不可控
• 只拷贝 .git 目录会丢失 index 状态、reflog、以及某些 Git 2.35 之前版本中因锁文件未释放导致的损坏风险
• Windows 上路径含空格或 Unicode 时，部分旧版 Git 对 .git 目录的硬链接/符号链接处理异常，恢复后 git status 可能报错
• 没有校验机制：损坏的 .git 目录可能直到执行 git log 或 git fsck 才暴露问题

恢复时常见错误与对应命令

bundle 恢复不是“解压即用”，clone 也不是“点开就行”，关键在 ref 的显式指定：

• 误用 git clone repo.bundle → 默认只取 HEAD，其他分支、tag 全丢；应改用 git clone repo.bundle my-repo（自动拉取全部）
• 误用 git pull repo.bundle main → 只拉一个分支；想全量恢复，进空目录后执行：git init && git pull ../repo.bundle --all
• 裸仓库恢复后发现缺少某些 tag？检查原仓库是否用了 git tag -a 但没推送到 origin —— --bare 克隆会包含所有本地 tag，但 git bundle 需确认 --all 是否生效
• 恢复后 git log 显示 commit 少一截？大概率是原仓库存在孤立提交（orphan commit）且无任何 ref 指向它——这类提交本就不在常规遍历路径中，git bundle 和 --bare 都不会主动打包

真正容易被忽略的是：无论用哪种方式，备份后必须立刻验证可恢复性。跑一次 git clone 或 git pull --all 成功，比看文件大小或存在性可靠得多。Git 不会在备份时做预校验，损坏往往在半年后第一次恢复时才暴露。