Rebasing everyone onto changed git history after filter-branch

Question

Our git repo has a bunch of large files in its history that are no longer needed. I want to remove them using the filter-branch technique explained in Pro Git:

http://git-scm.com/book/en/v2/Git-Internals-Maintenance-and-Data-Recovery

I'll then use git push --force all to send this to our shared repo, as explained here:

Update a development team with rewritten Git repo history, removing big files

BUT. Pro Git says I'll need to have everyone rebase since I'm changing history. We've only sparingly used rebase, usually just as an alternative way to merge. I can have everyone re-clone, but that's a last resort; several devs have local branches with changes they'd like to keep.

So: What exactly will everyone need to do in our local repositories to rebase onto the newly-changed shared repo? And do we have to do it once per tracking branch? Our repo is referred to as origin and the master branch is master, if you want to give step-by-steps (and I'd love it if you would).

Answer 1

The key is for each individual developer not to lose their original reference to master until after they've done their rebase. To do this, have them do a fetch (not a pull) after the forced push, then for each local branch, do:

git rebase --onto origin/master master <local_branch>

When that's done, then they can checkout their master and update it by:

git pull --force