问题描述
我正在使用包含生成的 PDF 的 a repo。显然这不是一个好主意,所以我们想从我们的存储库历史中删除它们。1我已经测试了 BFG Repo-Cleaner 并且结果非常好。现在在我的机器上克隆我的 fork 快了 12 倍。2但是有一个问题阻碍了我今天做出改变:3
此时,您已准备好让每个人都放弃他们的旧存储库副本,并为漂亮的新原始数据做新的克隆。最好删除所有旧克隆,因为它们将具有您不想冒险推回新清理的存储库的脏历史记录。
理论上,我们可以告诉组织中的每个人删除他们的回购副本,但肯定有组织外的人拥有我们不知道的副本。 (就此而言,我可能有我不记得制作的副本。)所以我们希望防止人们在清除后推送 PDF 文件历史记录。
一种解决方案可能是某种 pre-push
hook,当我们删除该历史记录后 Git 历史记录仍然包含 PDF 时,它会阻止推送。但是我们应该检查什么?有没有其他方法可以避免从没有听说应该重新克隆存储库的人那里取回所有这些历史记录?
脚注:
-
目前我们是 moving them to LFS,但我想说明一点,我们根本不跟踪生成的二进制文件。
-
除了周末做出大的改变不是一个好主意。
解决方法
首先,从 Git 历史记录中删除文件并不是那么难。最坏的情况,重新运行 BFG 进程。最好的情况是你什么都不做,每个人要么听从指示,要么不试图推送肮脏的历史。
Ideally 使用 pre-recieve
钩子来阻止服务器端的恶意推送。看起来这是a possibility with GitHub Enterprise。如果这不是一个选项,using a Husky pre-push
hook 应该可以解决问题。我的做法是look for a particular commit我们知道不应该存在。
#!/bin/sh
git show 5c11439d7ade68daa9a3cb72271814ea8575e4f4 -s
if [ $? = 0 ]; then
echo "Looks like you have a copy of the repository with a bad commit."
echo "Please save your work to a temporary location and delete this repository."
echo "If you create a fresh clone,that should fix this problem."
exit 1
fi
您检查哪个提交并不重要,只要它会被 BFG 步骤删除即可。当您从 Git 历史记录中删除 PDF 时,请立即添加挂钩(pre-recieve
或 Husky pre-push
)以确保新推送不包括不需要的提交。
我相信 push the Husky hook to all branches 也有必要确保每个人都拥有它。对于服务器端 pre-recieve
钩子,这应该不是必需的。