git clone --mirror 是唯一能完整复制所有引用的操作，创建裸仓库并原封不动镜像 heads、tags、remotes/origin/* 等全部 refs，目录名带 .git 后缀，仅用于备份、同步或迁移，不支持 git status 或 checkout。
能保留全部提交历史，但必须用对命令、顺序和条件——错一步，分支就丢、标签就断、LFS文件就空。
git clone --mirror 是唯一能完整复制所有引用的操作
普通 git clone 只拉默认分支（main 或 master），远程分支、refs/pull/*、甚至某些 GitLab 特有的合并请求引用都不会带过来。只有 git clone --mirror 会创建一个裸仓库，把所有 refs（包括 heads、tags、remotes/origin/*）原封不动镜像下来。
- 执行后目录名带
.git后缀（如my-project.git），这不是工作区，别试图cd进去改代码 - 不支持
git status或git checkout，只用来推送 - 如果源仓库用了 Git LFS，
--mirror不会自动 fetch LFS 对象，迁移后需手动在目标端补：git lfs fetch --all
git push --mirror 必须确保目标仓库为空且无保护分支拦截
git push --mirror 不是“推分支”，而是把本地所有 refs 强制覆盖到远端对应位置。这意味着它会删掉目标仓库里任何不在源仓库中的分支或标签——所以目标仓库必须是全新创建的空白项目。
Github Stars Analyzer
下载
抓取指定 GitHub用户的 Stars 项目，生成标准化中文 Markdown 报告。用户提及「分析 GitHub stars」「导出收藏项目」「汇总 GitHub 星标」「生成 stars 报告」或粘贴含 ?tab=stars 的链接时触发。执行通过 bash...
- 常见报错
! [remote rejected] master -> master (pre-receive hook declined)：目标 GitLab 的master分支被设为受保护，且未开启 “Developers can push” 权限 - 解决方式不是换分支推，而是临时关闭保护，或让管理员用维护者权限执行推送
- 如果目标仓库已有初始提交（比如自动生成的 README），
--mirror会失败，必须先清空或重建项目
用 git remote set-url + git push --all --tags 更灵活但容易漏引用
适合只想同步常规分支和标签、不关心 PR 引用或 CI 配置的轻量迁移。它比 --mirror 安全，不会误删远端多余分支，但也不传 refs/merge-requests/* 这类非标准引用。
- 先
git clone普通仓库，再git remote set-url origin <new-url></new-url>，最后分两步：git push --all origin+git push --tags origin - 注意：
--all只推本地已跟踪的远程分支（即git branch -r里出现过的），如果本地没git fetch --all过，就会漏掉源仓库新增的分支 - 验证是否推全：对比
git ls-remote --heads origin和git ls-remote --heads <old-url></old-url>输出行数
GitLab 原生导出/导入不等于 Git 历史迁移
GitLab 导出包（.tar.gz）包含问题、MR、Wiki 等元数据，但它的 Git 数据是重新打包的快照，不是裸仓库引用流。导入后历史提交哈希一致，但部分低层引用（如 refs/notes/*、自定义钩子配置）可能丢失。
- 适合需要保留 Issue 和 MR 关联关系的团队协作场景，不适合依赖 Git 底层引用做自动化（如 CI 中解析
refs/pull/123/head） - 导入后务必运行：
git ls-remote --heads origin和git ls-remote --tags origin，确认分支/标签数量与源一致 - LFS 文件不会随导出包迁移，导入后需单独执行：
git lfs migrate import --include="*.psd,*.zip"并重推
最易被忽略的一点：所有方法都依赖源仓库在迁移窗口期内冻结写入。哪怕只多一次 git push，新提交就不会出现在你的镜像克隆里——历史是静态快照，不是实时同步管道。
