TLDR：
我有一个应用程序的 git 存储库，该应用程序具有许多分支，用于不同的进行中版本。我需要有这个 repo 的多个副本，可以在不同的分支或提交中签出（错误的术语？），但实际上没有保留多个副本以及可能的冗余文件。
长版：
我正在与一个试图提高性能的团队一起开发一个应用程序。这是一个非常经验性的过程，不同的方法都在各自的分支中实现，并且需要进行大量测试来选择最有效的方法。
我正在他们自己的分支中开发几种方法，并对应用程序的多个版本进行性能和正确性测试。为了保留多个构建，我只需为每个版本创建一个副本，并使用该版本进行构建，该版本安装到特定于版本的位置，脚本允许我选择在当前环境中使用的版本。
正确性测试系统不允许在同一源代码树中进行并发测试。所以如果一个版本本身有多个配置，就不能同时测试它们。因为有时可能需要一个小时才能完成这个测试，所以我只是简单地为每个配置提供了源代码树，并且如上所述，在单独的位置构建和安装。这允许我同时运行多个测试。
虽然这不是我理想的设置，但我的问题是这一切都是在大学 HPC 集群上完成的，它有一些非常严格的磁盘配额。用户的 /home 目录只能包含 15Gb 的数据，但我的文件数量不受限制。用户的 /extra 目录（系统特定的存储系统）可以有 200Gb 的数据，但每 GB 磁盘存储（在本例中为 200*600 或 120000）可能只有 600 个文件（包括目录）。不幸的是，我的设置超出了 /home 上的磁盘配额，以及 /extra 上的文件计数配额。
一位朋友建议了他的过程，即根据需要对目录进行 tar/untar。这个额外的过程听起来像是已经很乏味的设置中的另一个痛点。
核心问题是 git 存储库有点大：磁盘上约 650Mb 和 +7500 个文件。我有大约 17 个这样的存储库，以及不同的库，以及许多性能测试的东西（这是相当重量级的），这使得这一切都超出了配额限制。如果我有一个精灵，我会要求它给我一个神奇的 git 存储库，它实际上只存在一次。每个“副本”看起来和行为都类似于 git 存储库的普通副本，其中包含可以编辑和提交的分支，而不会破坏任何其他分支。但实际上，该副本是系统维护的“视图”。
问题：
像我的魔法愿望这样的东西存在吗？
时间和资源有限的人如何有效地管理这个问题？（所有这些工作有点像构建农场/CI 测试的东西。）
我知道主要的答案是“只是删除一些存储库”，我会这样做，但我确实在一周的不同时间使用其中的一些，并且不得不玩'wack-a-回购'会很痛苦。