Question

I git the purpose of rebase. It makes sense to me. Basically i I have a feature branch I’m working on and I’m ready to put it into the master branch I would do a rebase to squash all of my commits into one clean one so that it’s easily integrated into master without all the messy history. Right?

Here’s what we’ve been doing.

1. Create a feature branch
2. Add a bunch of commits as we build the feature
3. Periodically merge the master branch into the feature branch (in order to avoid a painful merge down the road)
4. When everything is done, merge feature branch into master

The problem I’m seeing is that periodically merging master into the feature branch causes problems when rebasing because now I have a bunch of master branch checkins mixed in amongst my feature checkins.

What’s the right workflow here? Where do the following commads come into play:

• git rebase -i Head^#
• git rebase master
• git merge master
• git-rerere
• git reset –hard HEAD^

Answer 1

You should only merge to/from master once, at the end of life of the branch. The idea of a feature/topic branch is that it only contains changes relevant to the feature; you lose that when you merge in master repeatedly. (You can read what Junio Hamano, the git maintainer, says about branches.)

You can do a “practice” merge, that you will throw away, and use git-rerere to have Git automatically record your merge resolutions, so that they can be re-used when you really are ready to merge. See http://www.kernel.org/pub/software/scm/git/docs/git-rerere.html for background and tutorial. This is really cool because it lets you do the work of the merge, without committing it anywhere explicitly, and then get that work back “magically” when you really are ready to create the merge. So, instead of one big painful merge at the end, you can do a bunch of smaller, hopefully simpler, intermediate “practice” merges along the way. Roughly speaking:

# Enable rerere
git config --global rerere.enabled 1
# Start a feature branch
git checkout -b feature
# Hack hack hack
git commit
git commit
# Practice merge
git merge master
# ...then throw the merge commit away, the work is saved by rerere
git reset --hard HEAD^
# Hack hack hack
git commit
# Really merge to master, reusing any saved work from rerere
git checkout master
git merge feature
git branch -d feature

See also http://progit.org/2010/03/08/rerere.html for another tutorial.

You can also periodically rebase your topic branch on top of master and then just do a merge at the end.

To deal with a situation like the one where you are currently in, with a topic branch (say named feature) that has a series of merges from main mixed with various in-progress commits, the easiest approach would be to do a squashed merge to produce a “merged” working tree and then create a new commit (or series of commits) on to main. For example:

git checkout master
git merge --squash feature
git commit

This will produce a single commit that represents the state of the tree at the head of feature, merged into master.

Of course, you can also just do a regular merge to master for this change, leaving the messy history of feature present, and just work more cleanly in the future. e.g., simply

git checkout master
git merge feature

and move on.