用重写的Git回购历史更新开发团队，删除大文件

Question

我有一个git回购，里面有一些很大的二进制文件。我不再需要它们了，我也不关心是否能够签出以前提交的文件。因此，为了减少回购规模，我想将二进制文件从历史记录中全部删除。

经过一次网络搜索，我得出结论，我最好的(只有？)选项是使用git-filter-branch

git filter-branch --index-filter 'git rm --cached --ignore-unmatch big_1.zip big_2.zip etc.zip' HEAD

到目前为止，这看起来是个不错的方法吗？

如果答案是肯定的，我还有另一个问题要解决。The git手册有此警告

警告！重写的历史记录将对所有对象都有不同的对象名称，并且不会与原始分支收敛。您将无法轻松地在原始分支之上推送和分发重写的分支。如果您不知道该命令的全部含义，请不要使用此命令，如果一个简单的提交就足以解决您的问题，请避免使用它。(有关重写已发布历史的进一步信息，请参阅git-rebase(1)中的“从上游重基中恢复”一节。)

我们的服务器上有一个远程回购系统。每个开发人员都会推拉它。基于上述警告(以及我对git-filter-branch工作方式的理解)，我认为我无法在本地副本上运行git-filter-branch，然后再推动更改。

因此，我初步计划通过以下步骤：

1. 告诉我的所有开发人员提交、推动和停止工作一段时间。
2. 登录到服务器并在中央回购系统上运行筛选器。
3. 让每个人删除他们的旧副本，并再次从服务器克隆。

这听起来对吗？这是最好的解决办法吗？

Answer 1

是的，你的解决方案会奏效的。您还有另一个选择:不要在中央回购系统上执行此操作，而是在您的克隆上运行筛选器，然后使用git push --force --all将其推回去。这将迫使服务器接受存储库中的新分支。这仅取代步骤2；其他步骤将相同。

如果您的开发人员精通Git，那么他们可能不必删除他们的旧副本；例如，他们可以获取新的遥控器，并根据需要重新设置主题分支。

Answer 2

您的计划是好的(尽管最好是在存储库的简单克隆上执行筛选，而不是在中央服务器上)，但与git-filter-branch相比，您应该更好地使用MyBFG回购-清洁，这是专门为从Git repos中删除大型文件而设计的一种更快速、更简单的git-filter-branch替代方案。

下载Java jar (需要Java6或更高版本)并运行以下命令：

$ java -jar bfg.jar  --strip-blobs-bigger-than 1MB  my-repo.git

任何大小超过1MB的blob (不在最近的提交中)都将从存储库的历史记录中完全删除。然后，您可以使用git gc清除死数据：

$ git gc --prune=now --aggressive

BFG通常比运行git-filter-branch快10-50倍，并且这些选项是围绕这两个常见的用例量身定做的：

• 删除疯狂大文件
• 删除密码、凭据和其他专用数据

Answer 3

如果您不让您的开发人员重新克隆，他们很可能会设法将大型文件拖回。例如，如果它们小心地连接到您将要创建的新历史记录上，然后发生在本地项目分支中的git merge上，而该本地项目分支没有被重新基于，则合并提交的父级将包括项目分支，该分支最终指向使用git filter-branch擦除的整个历史记录。