我几乎可以肯定答案了，但我还是要问
我需要发布回购的Git历史记录到新服务器，但仅从现在开始。也就是说，将当前提交日志压缩为初始提交，并从现在开始创建新历史记录。理想情况下，当前服务器应保留完整的历史记录和新提交，而第二台服务器仅保留其中一台，从现在开始。
据我所知git的目的是避免这种混乱，但我可能并不了解所有功能：）
EDIT ：我可能还不够清楚：我想将当前历史记录保留在实际服务器上，将 start 的新历史记录保留在新的镜像远程服务器上服务器。我不想从头开始
答案 0 :(得分：0)
tl; dr 可以，但是这很痛苦，并且放弃了Git的大部分价值。
我猜您将要公开一个私有存储库，并且其中有些内容不希望您看到。密码，商业机密，向客户起誓等...除了在发布之前扔掉您的历史记录之外，还可以重写历史记录以确保发布的安全性。使用git filter-branch and git rebase -i选择性地重写历史记录，并使用the BFG Repo Cleaner批量删除文件。
然后，您可以发布刚清理的，不太尴尬的存储库。
我认为您想要两个这样的存储库。
A - B - C - D - E - F - G [master]
Q - E - F - G [master]
A - B - C - D是未压缩的历史记录，Q是压缩的提交，而E - F - G是向前的提交。
您能得到的最好的就是这个。
A - B - C - D - E - F - G [master]
Q - E1 - F1 - G1 [master]
E1 - F1 - G1与E - F - G的内容相同，但是它们具有不同的提交ID。完全不同的提交ID。完全不相关的提交ID。它太乱了，它抛弃了Git的所有功能。
Git提交是该提交的内容 加上所有以前的提交 。提交ID是提交的所有内容，日期，作者和日志消息之类的内容的校验和，以及父提交的提交ID。如果通过挤压更改存储库，则将更改提交ID，并更改位于其顶部的每个提交的提交ID。如果更改提交ID，Git将不再认为它们是相同的提交。
要完成您想要的工作，必须在壁球之后基本上替换每个提交，就好像它是新存储库顶部的新提交一样。 git cherry-pick将执行此操作。这些提交将获得新的提交ID，因此Git不会将它们识别为相同的提交。您必须手动管理上次选择樱桃的时间。
例如，您将原始存储库设置为压缩存储库的远程目录，并设置了一个标签来跟踪同步点。
[sync]
A - B - C - D [origin/master]
Q [master]
您通常会git fetch来获取更新。
[sync]
A - B - C - D - E - F [origin/master]
Q [master]
然后从同步点开始进行选择。
git cherry-pick sync..origin/master
[sync]
A - B - C - D - E - F [origin/master]
Q - E1 - F1 [master]
并更新同步点。
[sync]
A - B - C - D - E - F [origin/master]
Q - E1 - F1 [master]
分支将很有趣。有可能您可以使用git rebase代替它来处理分支。