How do I manage merging and rebasing in git?

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 c开发者_JAVA百科lean 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^

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.

If you're going to rebase (which I suggest you do), then don't ever merge from master. A rebase workflow is based on the idea that a topic branch consists of the path from master to the new feature and nothing else. As master moves forward, then your changes to get toward the new feature move with it.

When you're finally ready to bring the changes into master, you have a two main options:

1. Rebase against master one final time, then do a normal fast-forward merge which essentially brings all your branch's commits into master one by one. This keeps a more granular history, but if intermediate commits broke the build then you may prefer to squash them. Interactive rebase (-i) can help arrange these commits.

2. Use merge --squash to make a single commit in master that contains all the branch's changes.

If you're going to rebase the branch anyway, just rebase whenever you want to "merge" changes in. You don't have to rebase + squash until you're ready to "merge" that branch into master.

I believe the short answer is:

use git merge --squash if:

if you have a feature branch and you are pulling from another branch into that branch as you work, for instance you switch to feature and run git merge master periodically to merge in the master branch. Or you are pulling or pushing that branch to others or to a central repo like github.

use git rebase if:

if you have a feature branch that you are not pushing or pulling to others, and you are not merging another branch into periodically, as described above