Best Practices for modifying shared Git history?

Question

Background: Our group of 10+ engineers all share a Git Repository. In the past, someone has checked in binaries that have caused the size of the repository to grow from ~10 MB to ~10GB. These unneeded binaries are slowing downloads considerably. I have found a tool/method for removing the binaries.

Plan: My plan is to copy Git Repository to Git Repository Old in BitBucket, then replace Git Repository with the new, improved, smaller new repository.

Question: What are the best practices for keeping the group from pushing code from Old Repository clones into the New Repository?

Answer 1

Communication is key. And organization as well.
There is no way you can avoid rewriting history and keep history in sync with all cloned repositories. Therefore your whole team has to cooperate on this to avoid unnecessary issues

0. Make sure the work created by the cleanup is really important enough to justify it. How often are you fully cloning a repository? If this rarely happens and only with a good connection, just treat it as an annoyance.
1. Make sure everybody understands the problem and its implications
2. Agree on a freeze window. This should be at a time when nobody is actively working and there should not be pending feature branches (Note that this can be a major issue)
3. Everybody delete their clone
4. Alter the repository
5. Everybody clones the altered repository and restart working

The critical point here is actually freezing development to be able to wipe the old clones. For 10 people this sounds somehow manageable but a single merge-commit with the old state can bring everything back. Afterwards make sure that this does not happen again, e.g. by adding pull requests and automatic checks

Answer 2

Unfortunately you are now stuck with the repo because you care.

If you don't want to be stuck with the repo you need to change the culture in your organisation. This is going to take time, and you will face resistance.

To start with:

1. Implement Pull Requests
   • Only add those people who undertake the training,
   • and have agreed to fix up any mistake that gets into the repo from a PR they approved.
   • Sell this as a tool to increase interteam communication, and increase the chance of detecting a mistake early. If need be dig through the last two years of mistakes and count how many of them were simple one line mistakes.
2. Add Automated and unskippable pull request checks.
   • ensure one of those checks is to check for binaries.
   • Sell this as reducing the need for expensive engineers to deal with trivial mistakes. Either by not requiring human review on PR's with known trivial mistakes, or by increasing the speed by which those engineers learn of these mistakes.

The engineers will soon realise that certain actions cannot happen, or else they have to redo their own work. No one likes redoing work, easier to just get it right first.

Some engineers will realise for one reason or another that they need/want to be approvers. They can thus willingly shoulder the responsibility along with the powers. Exactly like an admin shoulders responsibilities along with powers.

Answer 3

Creating a new repo won't help you. It's basically the same thing as asking people to delete their local repos and reclone. You really need to be focusing on preventing changes like that from getting into the repo in the first place, because that's the problem you're back to.

Your fix is going to alter history, so most of the ways the old changes would be able to get back in are also history altering. If those changes can be made in your central repo without someone who understands git approving, you have bigger problems.