我有一个大型的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拉--rebase --all 然后初始化一个降序分支 Git TFS分支--init [分支名称] 然后再拉一次等
这给出了共同的祖先和分配合并提交历史，允许更小的回购，但是以合并历史为代价。
答案 0 :(得分：1)
如果不知道存储库中包含的内容以及要保留的内容，则很难回答。
但是如果你有一个大约100-200MB的工作目录，你必须有很多二进制文件。
我确信第一步是使用非常好用且易于使用的工具删除所有二进制文件，bfg report cleaner
然后，您将看到存储库的大小是否仍然存在问题。
Ps：在重写历史记录之前保留存储库的备份。至少，如果你需要的话，它最终将是你的只读参考资料库......
编辑：事实上，我在bitbucket上搜索了这个限制，并通过2个非常有趣的链接找到this page：How to handle big repositories with git 和Reduce repository size