更新
我找到了另一种稍微简单的方法，使用git rebase 的--root 标志。我用我的一个 repo 进行了尝试，所以我知道它是有效的（至少对于完全 linear 的历史，最后会详细介绍）。
第 1 步：创建存储库的备份克隆
让我们谨慎行事并进行备份，以防万一我们最终做出灾难性的事情并丢失您的数据：
git clone original-repo backup-repo
第 2 步：创建孤立分支（这将是您的新根）
检查孤立分支。指定起点提交/分支是可选的，如果您不考虑该参数，那么 Git 将默认使用您当前的提交作为起点（它遵循标准分支语法的模式）：
git checkout --orphan new-master firstCommitOfOldMaster
我指定了旧 master 的根目录作为起点，因为它可能会使接下来的步骤更快（删除工作目录文件）。
第 3 步：删除工作目录文件
从您的旧 master 创建孤立分支 new-master 可能会在您的工作目录和索引中留下文件，具体取决于您分支的提交中文件的状态：
索引和工作树的调整就像您之前运行过git checkout <start_point> 一样。这允许您通过轻松运行git commit -a 来创建一个新的历史记录，该历史记录记录一组类似于<start_point> 的路径以进行根提交。 — git checkout docs
您现在要做的是彻底清除分支的状态，以便您真正从头开始（从顶级文件夹运行）：
git rm -rf .
这是来自文档的解释：
如果你想开始一个断开的历史记录，记录一组与<start_point> 完全不同的路径，那么你应该在创建孤立分支后立即通过运行git rm -rf . 清除索引和工作树从工作树的顶层开始。之后，您将准备好准备新文件、重新填充工作树、从其他地方复制它们、提取 tarball 等等。
第 4 步：将旧工作重新提交到 new-master
现在您需要开始将您的旧工作提交到new-master。完成后，您将重新调整旧主人的基础。
我不确定你的备份文件夹是如何组织的，但我会假设每个都是你的项目文件夹的一个有日期的副本，以YYYY-MM-DD 格式命名，例如2013-01-30。您可以手动将每个文件夹的内容添加为新的提交，也可以编写脚本来自动执行该过程。
假设您将所有备份文件夹放在名为backup 的顶级文件夹中，该文件夹与您的主项目文件夹位于同一目录中。然后这里是一些用于自动化提交每个文件夹过程的脚本的伪代码：
# Get backups and sort them from oldest to newest
backups = open("backups").toList().sort("date ascending")
for each (backup in backups)
copy files from backup to project folder
execute `git add "*"`
execute `git commit --date="#{backup.date}" --message="#{backup.date}"`
上面的脚本只会在提交之间添加和修改文件。如果您的任何备份被删除、移动或重命名，脚本将不会记录这些。您需要编写一个更聪明的脚本来执行此操作（可能使用 git diff 或其他一些差异工具），或者手动记录这些更改。
第 5 步：将旧的 master 重新定位到 new-master
看看 GIT 的强大力量！ 现在我们要重写你的整个历史！ 背诵这些神秘的力量话语，见证奇迹发生！：
git rebase --onto new-master --root master
TA-DA！您可能需要解决new-master 的最后一次提交和master 的首次提交之间的冲突，但除此之外，应该就是这样！
--root 标志 rebase 解决了我们之前遇到的问题，即rebase 通常不会在 Git 存储库的第一个（根）提交上运行。 --root 标志基本上告诉 Git 将其包含在 rebase 中：
对所有可从<branch> 访问的提交重新设置基准，而不是用<upstream> 限制它们。这允许您在分支上重新设置根提交。当与--onto 一起使用时，它将跳过已经包含在<newbase> 中的更改（而不是<upstream>），而没有--onto 它将对每个更改进行操作。 — rebase docs
第 6 步：验证最终提交是否仍然相同
为了确保我们没有弄乱任何代码，我们需要将master 的当前最终状态与执行rebase 之前的状态进行比较。以下任一命令都将起作用（它们是相同的）。在master 分支上：
git diff orig_head # "Original" head
git diff master@{1} # Master at its 1st prior position
如果您没有从 diff 得到任何输出，那么这意味着您重新定位的 master 的最终状态与 rebase 之前的状态相同。干得好！
注意：不确定合并提交会发生什么...
现在，如果您有完美的线性历史记录，即您没有任何合并提交，上述步骤将可以正常工作。我不确定如果你这样做它是否仍然有效。在我之前的回答中，我提到将--preserve-merges 标志与rebase 一起使用可能会帮助您保持这些合并，但文档中提到该标志还与--onto 和--root 标志交互：
当 [--root] 与 --onto 和 --preserve-merges 一起使用时，所有根提交都将被重写为以 <newbase> 作为父提交。 — rebase docs
目前我不确定这意味着什么……我可能需要尝试一下，看看会发生什么。这是否意味着如果您有超过 1 个根提交（例如 10 个），那么这些根提交中的 9 个最终将重新定位到作为新根的最后一个？这似乎不是我们想要的行为。我们只想保留一个根被重新定位到另一个根的合并提交。
上一个答案
MGA 有the right idea with rebase。我不确定这是否能解决您的问题，但也许您需要在您的存储库中进行新的根提交，将您的备份文件作为新提交添加到它之上，然后在顶部重新设置您的旧提交图。
例如，git checkout 根据the documentation 有一个--orphan 标志：
--orphan <new_branch>
创建一个新的孤立分支，命名为<new_branch>，从<start_point> 开始并切换到它。在这个新分支上进行的第一次提交将没有父级，它将成为与所有其他分支和提交完全断开的新历史的根。
也许你可以试试
git checkout --orphan <temp_branch>
然后将您的备份文件提交给它。然后temp_branch 签出，做
git cherry-pick <first commit from master>
git rebase --onto temp_branch <first commit from master> master
我认为您可能需要cherry-pick 第一次提交，因为rebase --onto 的第二个参数是您要变基的分支的旧基础（在本例中为master），而旧基础不是' t 包括在内。所以这就是为什么我认为你需要 cherry-pick 才能得到它，因为它本身没有基本提交，所以你不能在 rebase 中为它指定一个。
还要注意，如果您的提交历史不是线性的（即它具有合并提交），那么rebase 通常不会保留这些。它有一个--preserve-merges 标志，但我以前从未使用过它，所以我不确定它是如何工作的。来自the docs：
-p
--preserve-merges
不要忽略合并，而是尝试重新创建它们。
这在内部使用了 --interactive 机制，但除非您知道自己在做什么（请参阅下面的错误），否则将其与 --interactive 选项明确结合通常不是一个好主意。
那么，也许所有这些都行得通？