完整实战指南)
教程知识库【免费下载链接】tech-interview-for-developer 신입 개발자 전공 지식 기술 면접 백과사전 项目地址https://gitcode.com/GitHub_Trending/te/tech-interview-for-developer点击查看免费下载本文源自仓库 ETC/GitHub 저장소(repository) 미러링.md 미러링.md)系统讲解如何把 GitHub 仓库原样搬迁到另一个远端仓库——不仅包含全部提交历史commit log、分支与标签还覆盖了仓库中存在超过 100MB 大文件时的进阶处理方案Git LFS BFG Repo Cleaner。读完本文你将能独立完成普通仓库镜像迁移与含超大文件仓库镜像迁移两条完整命令链路并掌握镜像迁移后的验证与注意事项。一、什么是仓库镜像Repository Mirroring仓库镜像的核心诉求是把一个仓库的所有 Git 引用refs——包括所有分支、标签、远端跟踪引用以及完整的 commit log——原封不动地复制到另一个通常是新建的仓库。它与日常使用的git clonegit push有本质区别操作行为局限git clone url只克隆默认分支附带工作区文件不保证携带全部分支/标签且夹带工作区无关内容git push --all url推送所有分支不推送标签、不删除远端多余引用git push --tags url只推送标签与分支推送需分开执行git push --mirror url推送全部 refs分支标签远端引用并让远端与本地完全一致含删除操作破坏性操作目标仓库会被完全覆盖因此镜像迁移是换托管平台仓库备份复制开源项目场景下的标准做法其优点正如原文档开篇所强调的以保留 commit log 为前提进行复制迁移后的仓库历史与源仓库完全一致git log、git blame、CI 历史等均不会丢失。二、镜像迁移的两个核心命令语义在执行具体步骤前先理解两条命令的底层行为这决定了后续操作的正确性git clone --bare url只复制 Git 对象数据库和引用即.git目录的全部内容不生成工作区也不会为源仓库配置自动跟踪的 refspec。它复制的是仓库本体适合作为搬运的中转载体。git clone --mirror url等价于--bare但额外把源仓库配置为镜像源refspec 为refs/*:refs/*即所有引用全部同步后续执行git remote update时会把源仓库完全同步过来包括删除本地已经消失的分支。原文档在普通仓库场景使用--bare、在超大文件仓库场景使用--mirror两处都可以完成搬运但--mirror的引用同步更彻底也更适合原样复制的诉求。git push --mirror url把本地所有 refs 推送到目标仓库并让目标仓库完全镜像本地状态——目标上存在而本地不存在的引用会被删除本质上是一组 force push。因此目标仓库必须是空仓库或确认可以被完全覆盖。原文档命令块中代码标注为bach应为bash的笔误本文统一按bash处理占位符{복사하고자하는저장소의 git 주소}源仓库地址与{붙여놓을저장소의 git 주소}目标仓库地址在真实执行时请替换为实际的 SSH/HTTPS 地址。三、场景一普通仓库的镜像迁移三步走这是原文档给出的标准流程适用于绝大多数仓库无超大文件、无 LFS 历史。下面以gitgithub.com:team/old-repo.git迁移到gitgithub.com:team/new-repo.git为例。1. 对源仓库创建 bare clonegit clone --bare gitgithub.com:team/old-repo.git执行后当前目录下会生成一个名为old-repo.git的目录bare 仓库约定以.git结尾命名它不包含工作区文件只包含完整的 Git 对象库、全部分支和标签。2. 以 mirror 方式推送到目标仓库cd old-repo.git git push --mirror gitgithub.com:team/new-repo.git请确保目标仓库new-repo.git已在 GitHub或其他托管平台上预先创建且为空执行时使用具有 push 权限的账号SSH key 或 HTTPS 凭据--mirror会一次性推完全部 refs无需再单独执行git push --tags。3. 删除临时克隆并收尾cd ..确认推送成功、验证无误验证方法见下文第五节后删除第 1 步生成的临时目录old-repo.git。原文档特别强调这一步因为 bare 克隆只是搬运中介不应留在本地污染工作环境。提示如果想确认迁移前后的引用完全一致可在推送前后分别执行git ls-remote 地址对比分支与标签列表。这也是原文档 GitHub Help 所推荐的复制仓库思路当前仓库同类主题可见 ETC/Git vs GitHub vs GitLab Flow.md 中关于分支与发布流程的讨论。四、场景二含 100MB 以上大文件的仓库镜像Git LFS BFG普通git push无法把超过 100MB 的单文件推送到 GitHub超过 50MB 通常就会收到警告GitHub 会拒绝包含超大文件的常规推送。这类仓库的镜像迁移需要先借助Git LFSLarge File Storage和BFG Repo Cleaner改写历史将大文件对象替换为 LFS 指针再执行镜像推送。原文档完整给出了这一流程。第 1 步安装 git-lfs 与 BFG Repo CleanerGit LFSGit 官方扩展将大文件内容存储到 LFS 存储服务仓库内只保留指针文件BFG Repo Cleaner用于快速改写提交历史的 Java 工具支持--convert-to-git-lfs选项可把历史提交中的大 blob 批量转换为 LFS 对象。安装完成后可通过git lfs version与java -jar bfg-1.13.0.jar --version验证环境就绪。第 2 步创建源仓库的 mirror clonegit clone --mirror gitgithub.com:team/old-repo.git此处使用--mirror而非--bare镜像仓库后续对引用执行的操作如 filter-branch 改写、引用同步会以源仓库为基准完整保留且 BFG 工具要求操作对象是一个完整的镜像克隆。第 3 步在提交历史中追踪大文件扩展名cd old-repo.git git filter-branch --tree-filter git lfs track *.{zip,jar} -- --all该命令针对所有分支--all的每个历史提交执行git lfs track把*.zip、*.jar等目标扩展名写入.gitattributes的追踪规则使这些路径在 LFS 体系中登记为受管对象。实战说明git lfs track本身需要在有工作区/可修改 tree 的环境下生效在 bare 镜像仓库中通过filter-branch --tree-filter在每个提交的树tree上执行是把追踪规则写入历史的可行方式。实际使用中请根据你自己的大文件类型调整通配符例如*.mp4、*.bin且扩展名需与下一步 BFG 命令保持一致。第 4 步用 BFG 将历史中的大文件转换为 Git LFSjava -jar ~/usr/bfg-repo-cleaner/bfg-1.13.0.jar --convert-to-git-lfs *.zip java -jar ~/usr/bfg-repo-cleaner/bfg-1.13.0.jar --convert-to-git-lfs *.jar参数--convert-to-git-lfs会扫描历史中匹配模式此处为*.zip、*.jar的 blob并将其内容替换为 LFS 指针把真正的大文件对象交给 LFS 存储路径~/usr/bfg-repo-cleaner/bfg-1.13.0.jar是原文档的示例安装位置请替换为你实际下载保存的 BFG jar 文件路径需要 Java 运行时环境对每一个需要转换的扩展名单独执行一次命令BFG 在执行后会重写引用refs改写完成后一般还需按工具的提示执行git reflog expire与git gc --prunenow --aggressive以彻底清理旧对象具体以你所用 BFG 版本的输出提示为准。第 5 步镜像推送到新仓库git push --mirror gitgithub.com:team/new-repo.git推送前同样需在托管平台创建空目标仓库并注意目标仓库需开通LFS 支持GitHub 仓库默认支持 LFS 功能关注托管平台对LFS 存储容量与带宽的配额超大文件迁移会产生相应的存储占用镜像推送会覆盖目标仓库务必确认目标为空仓库或可覆盖。第 6 步删除临时镜像仓库确认目标仓库拉取验证通过后删除第 2 步生成的old-repo.git临时目录原文档此处编号为1번实为第 2 步生成的克隆逻辑一致迁移即完成。五、镜像迁移后的验证与收尾迁移不是推完就结束建议按下表逐项验证验证项命令预期结果引用一致性git ls-remote 新仓库地址与git ls-remote 源仓库地址对比分支、标签列表完全一致提交历史完整性git clone 新仓库地址后执行git log --oneline --all所有分支历史与源仓库一致无丢失大文件是否转为 LFS在新克隆中执行git lfs ls-files出现迁移前被追踪的*.zip/*.jar等 LFS 文件远端配置新克隆中执行git remote -v指向目标仓库日常同步型镜像例如定期备份可在配置remote add --mirrorpush后反复执行git push 远端保持镜像与源仓库持续一致。仓库协作场景下的远端配置、分支同步可参考仓库内的 ETC/GitHub Fork로 협업하기.md。六、常见问题与注意事项--mirror是破坏性操作git push --mirror会删除目标仓库中本地不存在的引用。务必只对空仓库或可覆盖的仓库执行执行前可先用git ls-remote确认目标状态。分支保护规则若目标仓库开启了分支保护如master禁止 force push镜像推送本质为 force 更新可能被拒绝迁移前需临时关闭保护或使用具备 admin 权限的账号。占位符与笔误原文档中bach应理解为bash{...}占位符均需替换为真实地址cd进入的目录名是 bare clone 生成的仓库名.git目录而非地址字符串。LFS 配额托管平台对 LFS 有存储/带宽配额限制超大文件迁移会产生相应消耗迁移前请确认配额充足。历史改写不可逆filter-branch与 BFG 都会重写提交哈希。若源仓库有外部协作方fork、下游 clone改写会导致历史不兼容请先在测试仓库演练再对正式仓库操作。适用边界以上命令链路以原文档为骨架、以 Git 官方行为为依据整理具体到你的 git 版本与托管平台GitHub / GitLab / Gitea 等规则差异建议先做小仓库演练验证。七、相关阅读本仓库的 ETC 目录还整理了多篇与 Git 协作强相关的文档可作为镜像迁移之外的配套知识ETC/Git vs GitHub vs GitLab Flow.mdGit Flow / GitHub Flow / GitLab Flow 三种分支工作流对比帮助决定迁移后仓库的分支管理策略ETC/GitHub Fork로 협업하기.mdFork 协作模式下的远端配置与 upstream 同步方法ETC/Git Commit Message Convention.md团队协作时的提交信息规范迁移完成后统一历史书写风格。以上内容整理自 README.md 所收录的新人开发者技术面经知识库本文聚焦于该知识库中GitHub 仓库镜像这一具体工程主题其余 Git 主题可继续在 ETC 目录 中查阅。赞分享教程知识库【免费下载链接】tech-interview-for-developer 신입 개발자 전공 지식 기술 면접 백과사전 项目地址https://gitcode.com/GitHub_Trending/te/tech-interview-for-developer点击查看免费下载相关推荐Vue.js Firebase 邮箱注册/登录实战基于 tech-interview-for-developer 仓库从项目初始化到用户认证的完整实现Vue.js Firebase 邮箱注册/登录实战基于 tech interview for developer 仓库从项目初始化到用户认证的完整实现 本教程知识库tech-interview-for-developer 技术面试备战指南从刷题训练到现场解题的完整方法论tech interview for developer 技术面试备战指南从刷题训练到现场解题的完整方法论 本篇指南以 tech interview for教程知识库技术社区参与终极指南如何通过tech-interview-for-developer项目提升技能与贡献开源技术社区参与终极指南如何通过tech interview for developer项目提升技能与贡献开源 tech interview for develo教程知识库上一篇PyCaret数据预处理处理缺失值的终极策略下一篇TRELLIS.2实战案例用单张图片生成可商用3D资产全流程创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考