12

我们正在运行一个中央 git 存储库 (gforge)，每个人都可以从中提取和推送。不幸的是，一些无能的同事认为将几个 10-100Mb 的 jar 文件推送到 repo 是一个好主意。因此，我们经常使用的服务器磁盘空间不足。

我们直到为时已晚才意识到这一点，大多数人已经撤下了新的大型回购。如果问题没有被推送，那么我们可以做一个 rebase 来剪掉那些巨大的提交并修复它，但是现在每个人都已经退出了，删除那个提交的最好方法是什么（或者做一个 rebase删除大文件），然后当每个人都想从/推入回购时，这不会造成混乱吗？

它应该是一个小的脚本仓库，但现在大小约为 700M :-(

4

5 回答 5

12

避免混乱的最简单方法是给服务器更多的磁盘。

这是困难的一个。删除文件也需要将它们从历史记录中删除，这只能通过git filter-branch. 例如，此命令<file>将从历史记录中删除：

git filter-branch --index-filter 'git rm --cached --ignore-unmatch <file>' \
--prune-empty --tag-name-filter cat -- --all

问题是这会重写 SHA1 哈希，这意味着团队中的每个人都需要重置到新的分支版本，否则会有一些严重的头痛风险。如果没有人在进行中并且你们都使用主题分支，那一切都很好。如果您更集中，您的团队很大，或者他们中的许多人在工作时保留肮脏的工作目录，那么没有一点混乱和不和谐就没有办法做到这一点。你可以花很长时间让每个人的本地工作正常。那写的，git filter-branch可能是最好的解决方案。只要确保你有一个计划，你的团队理解它，并确保他们备份他们的本地存储库，以防一些正在进行的重要工作丢失或被破坏。

一种可能的计划是：

  1. 让团队生成他们正在进行的工作的补丁，例如git diff > ~/my_wip.
  2. 让团队为他们已提交但未共享的工作生成补丁：git format-patch <branch>
  3. 运行git filter-branch。确保团队知道在这种情况下不要拉动。
  4. 让团队问题git fetch && git reset --hard origin/<branch>或让他们重新克隆存储库。
  5. 应用他们之前承诺的工作git am <patch>。
  6. 应用他们正在进行的工作git apply，例如git apply ~/my_wip。
于 2012-07-09T14:52:50.453 回答
7

看看这个https://help.github.com/articles/remove-sensitive-data。他们在这里写了关于从你的 Git 存储库中删除敏感数据的文章，但是你可以很好地使用它来从你的提交中删除大文件。

于 2012-07-09T14:47:24.517 回答
4

除了其他答案之外，您可能需要考虑添加一些针对未来巨型 jar 文件的先发制人保护，其形式是回购中禁止用户（或至少是“非管理员用户”）的预接收挂钩的形式从推送非常大的文件，或名为 的文件*.jar，或任何看起来最好的文件。

我们以前做过这种事情，包括禁止特定的提交 ID，因为某些用户无法掌握“将你的工作保存在临时分支上，重置和拉取，并重新应用你的工作，减去巨大的文件”。

请注意，pre-receive 钩子在一个相当有趣的上下文中运行：文件实际上已经上传，只是引用（通常是分支头）实际上还没有改变。您可以防止分支头更改，但您仍将使用（临时，直到 gc'ed）磁盘空间和网络带宽。

于 2012-07-10T02:06:16.430 回答
2

使用过滤器分支！ 

git filter-branch --tree-filter 'find . -name "*.jar" -exec rm {} \;'

然后只需清除所有没有任何文件的提交：

git filter-branch -f --prune-empty -- --all
于 2015-05-07T23:24:35.023 回答
-1

GForge 家伙在这里。即使认为这主要是一个 git 问题，我还是想提供两件事：

  1. 从 GForge 6.3 开始，站点管理员可以识别使用过多磁盘的项目，以及旧项目和孤立项目。这可能会帮助您避免磁盘满的情况，尤其是在您有很多单独的团队和项目的情况下。
  2. 在 GForge 中轻松实现 git 钩子（通常是 SCM 钩子）。站点管理员可以配置任意数量的挂钩命令，然后项目级人员可以选择他们想要的项目挂钩。添加一个阻止某些类型（或大小？）文件的钩子将非常适合此功能。
于 2016-10-15T16:28:04.650 回答