Git 如何将旧仓库迁移新仓库中，但不显示旧的提交记录

在这里插入图片描述

一、异常错误

场景：我想把旧仓库迁移新仓库中，放进去之后，新仓库会显示这个项目之前的所有提交，如何不显示这些旧的提交？

二、原因

我们需要将旧仓库迁移新仓库中，但是又不想在新仓库中显示旧的提交记录，因为旧的提交记录包含一些敏感信息，我们只想在新仓库中保留最新的代码历史记录。

三、解决方法

我们可以使用下面步骤来解决。`注意先备份原有仓库的代码，以防止数据丢失。

创建一个新的空白仓库，例如使用GitHub或GitLab创建一个新的仓库。
将旧仓库的代码clone到本地。
进入项目的本地仓库目录，使用以下命令将其转换为一个新的仓库：

# 初始化本地仓库
git init

# 将旧仓库与本地仓库关联，<旧仓库的远程地址> 替换为实际的旧仓库地址
git remote add origin <旧仓库的远程地址>

# 从远程仓库中获取所有分支和标签的最新信息
git fetch --all

# 将本地的当前分支（默认为master）重置为与远程仓库的origin/master分支一致，
# 如果有未提交的改动将会被丢弃。此步骤用于确保本地代码与远程仓库的主分支保持同步。
git reset --hard origin/master

查看远程库的信息,删除旧的关联的origin的远程库

#查看远程库的信息
git remote -v

#删除旧的关联的origin的远程库
git remote rm origin

更换仓库关联，将新仓库与本地仓库关联

# 将新仓库与本地仓库关联，<新仓库的远程地址> 替换为实际的新仓库地址
git remote add origin <新仓库的远程地址>

在这里插入图片描述

使用以下命令清除旧的提交记录：

# 创建一个名为latest_branch的孤儿分支，该分支不会继承任何提交历史
git checkout --orphan latest_branch

# 添加当前目录下的所有文件到暂存区，准备提交
git add -A

# 提交暂存区的所有更改，并附上提交信息："Initial commit"
git commit -am "Initial commit"

# 删除本地的master分支
git branch -D master

# 将当前的latest_branch分支重命名为master
git branch -m master

# 强制推送master分支到远程仓库的origin/master，这将覆盖远程仓库中的master分支
# 注意：此操作会丢失远程仓库master分支上的历史记录和未合并的提交，请谨慎使用！
git push -f origin master

这样就可以将旧仓库迁移新仓库中，但不显示旧的提交记录

Git 是什么？
那么，简单地说，Git 究竟是怎样的一个系统呢？请注意接下来的内容非常重要，若你理解了 Git 的思想和基本工作原理，用起来就会知其所以然，游刃有余。在学习 Git 时，请尽量理清你对其它版本管理系统已有的认识，如 CVS、Subversion 或 Perforce，这样能帮助你使用工具时避免发生混淆。尽管 Git 用起来与其它的版本控制系统非常相似，但它在对信息的存储和认知方式上却有很大差异，理解这些差异将有助于避免使用中的困惑。

直接记录快照，而非差异比较
Git 和其它版本控制系统（包括 Subversion 和近似工具）的主要差别在于 Git 对待数据的方式。从概念上来说，其它大部分系统以文件变更列表的方式存储信息，这类系统（CVS、Subversion、Perforce 等等）将它们存储的信息看作是一组基本文件和每个文件随时间逐步累积的差异（它们通常称作基于差异（delta-based）的版本控制）。

存储每个文件与初始版本的差异。
Figure 4. 存储每个文件与初始版本的差异.
Git 不按照以上方式对待或保存数据。反之，Git 更像是把数据看作是对小型文件系统的一系列快照。在 Git 中，每当你提交更新或保存项目状态时，它基本上就会对当时的全部文件创建一个快照并保存这个快照的索引。为了效率，如果文件没有修改，Git 不再重新存储该文件，而是只保留一个链接指向之前存储的文件。 Git 对待数据更像是一个快照流。

Git 存储项目随时间改变的快照。
Figure 5. 存储项目随时间改变的快照.
这是 Git 与几乎所有其它版本控制系统的重要区别。因此 Git 重新考虑了以前每一代版本控制系统延续下来的诸多方面。 Git 更像是一个小型的文件系统，提供了许多以此为基础构建的超强工具，而不只是一个简单的 VCS。稍后我们在Git 分支讨论 Git 分支管理时，将探究这种方式对待数据所能获得的益处。