An alternative to git-filter-branch

The BFG is a simpler, faster alternative to git-filter-branch for cleansing bad data out of your Git repository history:

Removing Crazy Big Files
Removing Passwords, Credentials & other Private data

The git-filter-branch command is enormously powerful and can do things that the BFG can’t - but the BFG is much better for the tasks above, because:

Faster : 10 - 720x faster
Simpler : The BFG isn’t particularily clever, but is focused on making the above tasks easy
Beautiful : If you need to, you can use the beautiful Scala language to customise the BFG. Which has got to be better than Bash scripting at least some of the time.

Usage

First clone a fresh copy of your repo, using the --mirror flag:

1	$ git clone --mirror git://example.com/some-big-repo.git

This is a bare repo, which means your normal files won’t be visible, but it is a full copy of the Git database of your repository, and at this point you should make a backup of it to ensure you don’t lose anything.

Now you can run the BFG to clean your repository up:

1	$ java -jar bfg.jar --strip-blobs-bigger-than 100M some-big-repo.git

The BFG will update your commits and all branches and tags so they are clean, but it doesn’t physically delete the unwanted stuff. Examine the repo to make sure your history has been updated, and then use the standard git gc command to strip out the unwanted dirty data, which Git will now recognise as surplus to requirements:

1 2	$ cd some-big-repo.git $ git reflog expire --expire=now --all && git gc --prune=now --aggressive

Finally, once you’re happy with the updated state of your repo, push it back up (note that because your clone command used the –mirror flag, this push will update *all* refs on your remote server):

1	$ git push

At this point, you’re ready for everyone to ditch their old copies of the repo and do fresh clones of the nice, new pristine data. It’s best to delete all old clones, as they’ll have dirty history that you don’t want to risk pushing back into your newly cleaned repo.

Examples

In all these examples bfg is an alias for java -jar bfg.jar.

Delete all files named ‘id_rsa’ or ‘id_dsa’ :

1	$ bfg --delete-files id_{dsa,rsa} my-repo.git

Remove all blobs bigger than 50 megabytes :

1	$ bfg --strip-blobs-bigger-than 50M my-repo.git

Replace all passwords listed in a file (prefix lines ‘regex:’ or ‘glob:’ if required) with ***REMOVED***wherever they occur in your repository :

1	$ bfg --replace-text passwords.txt my-repo.git

Remove all folders or files named ‘.git’ - a reserved filename in Git. These often become a problemwhen migrating to Git from other source-control systems like Mercurial :

1	$ bfg --delete-folders .git --delete-files .git --no-blob-protection my-repo.git

For further command-line options, you can run the BFG without any arguments, which will output text like this.

Your current files are sacred…

The BFG treats you like a reformed alcoholic: you’ve made some mistakes in the past, but now you’ve cleaned up your act. Thus the BFG assumes that your latest commit is a good one, with none of the dirty files you want removing from your history still in it. This assumption by the BFG protects your work, and gives you peace of mind knowing that the BFG is only changing your repo history, not meddling with the current files of your project.

By default the HEAD branch is protected, and while its history will be cleaned, the very latest commit (the ‘tip’) is a protected commit and its file-hierarchy won’t be changed at all.

If you want to protect the tips of several branches or tags (not just HEAD), just name them for the BFG:

1	$ bfg --strip-biggest-blobs 100 --protect-blobs-from master,maint,next repo.git

Note:

Cleaning Git repos is about completely eradicating bad stuff from history. If something ‘bad’ (like a 10MB file, when you’re specifying --strip-blobs-bigger-than 5M) is in a protected commit, it won’t be deleted - it’ll persist in your repository, even if the BFG deletes if from earlier commits. If you want the BFG to delete something you need to make sure your current commits are clean.
Note that although the files in those protected commits won’t be changed, when those commits follow on from earlier dirty commits, their commit ids will change, to reflect the changed history - only the SHA-1 id of the filesystem-tree will remain the same.