我有一个大型的 TFS 团队项目。
在与 Git-TFS（我们的 TFS 团队项目中有一些时髦的东西）战斗之后，我有了一个完整的本地 git 存储库。
它太大而无法适应 BitBucket 1GB 软限制。
Team 项目包含不同产品的分支。
-- 基础产品（主干）
--- 客户端 A 产品（来自主干）
--- 客户端 B 产品（来自主干）
---- 客户端 B 功能分支（来自 B）
--- 客户端 C 项目（来自主干）
- --- 客户 D 项目（来自 C）
----- 客户 E 项目（来自 D）
如您所见，在 TFS 中进行分支时，我们对自己并不友善。
进行浅克隆显示任何分支的单个提交大约为 150-200MB。任何给定分支的完整历史记录不到 1GB
我提议为每个分支做一个 git repo，并在分支提交后推送分支历史。这意味着没有一个分支有共同的祖先，当想要进行跨 TFS 分支合并时会强制进行无根据的合并。我还建议通过执行积极的 GC 并删除一些大对象来存储只读的完整历史存储库，这使我可以将全部内容压缩到一个存储库中。这至少开辟了在未来某个时候进行移植或替换+rebase 以将“当前”回购与历史回购结合的可能性。
我无法在任何时候都干净利落地削减历史记录（和变基），以在 1GB 限制下提供合理的共同祖先和回购空间。
任何人都可以帮助制定更好的迁移策略吗？
更新1：这个问题的子文本是......当产品出现分歧时，分支结构有多重要。我们遇到的一个重要问题是分支之间的合并提交关系。如果我修剪历史记录，它还会迫使我在某些情况下处理合并提交历史记录（因为我们已经完成了从一个分支的早期部分到另一个分支的晚期部分的疯狂合并）
更新 2：我有另一种策略，无需所有合并历史记录，但保留原始父分支血统。使用 -c 选项的 Git TFS 快速克隆可在所需时间点创建起点。Git TFS pull --rebase --all 然后初始化一个降序分支 Git TFS branch --init [branch name] 然后再次拉取等
这给出了合并提交历史的共同祖先和分配，这允许更小的存储库，但以合并历史为代价。