Removing unwanted files to reduce git repository size

Question

As the result of a comedy of errors, a few directories of images totaling about 500MB was added to our git repository a while ago. While the files were removed, the history obviously still contains the repository size is much larger than it should be.

This occurred a while ago, and there have been thousands of commits since. I've done some research and it looks like the best course of action would be to use a git filter-branch to re-write the history to remove these unwanted (but not sensitive) directories.

Is that correct? If so, what is the best course of action for the (small) team of developers and multiple staging/production sites to avoid the pitfalls of history rewrites?

Answer 1

An alternative to git filter-branch is BFG Repo Cleaner which can do simple tasks like this in a fraction of the time, and takes makes it simpler to make sure that all your tags are copied correctly. It also automatically translates hashes that are included in commit messages correctly.

As always when rewriting history, there can be issues. You will have to force fetch all locations that normally use the default fetch.

Any developers that have outstanding branches that have not been pushed to the main repository should be able to rebase onto the new history as follows:

git rebase --onto <new-branch-base> <old-branch-base> <branch-name>

<new-branch-base> is the hash of the commit that you want to the branch to diverge from. <old-branch-base> is the hash of the commit that is a copy of the <new-branch-base>