Best-Practice "Merge vs. Rebase" searched...

[Scott Chacon]

Hey,

On Tue, Oct 20, 2009 at 6:04 AM, Alexander Schatten
<ml_alexanderschatten at gmx.at> wrote:
> Now, can anyone of you experts give me a more founded opinion? Point me to some good sources?

Rebasing is mostly used in the Git world to treat topic branches as
patch queues.  I think in the Mercurial world, it is much more common
to use the 'mq' extension for maintaining series of patches against an
upstream project.  In the Git world however, patch queue systems are
pretty rarely used because the branching system works fine.  Normally
you would start a new branch for some new topic (like you would start
a new patch queue), do a few commits on it and then extract that work
into patches (via format-patch) and send them to the maintainer.
Rebase normally comes into play if the maintainer does not accept them
quickly and the mainline moves forward.  If the patches no longer
merge without issues, then the contributor can run 'rebase' to
re-apply the topic branch onto the new upstream branch head, re-export
the patch series which is now known to apply cleanly and re-send it to
the maintainer (just like you would pop a patch series off, update,
then push the series back on in mq - rebasing is just sort of an
automated way to do that in a branchy world).

Keeping your history flat is _sometimes_ why it is used, but that's
mostly for using Git with a Subversion server, which needs to have a
flat history - in general, merging vs rebasing for bringing in
external changes doesn't really matter either way.  Merging tends to
be more common because then the commit SHA doesn't change which tends
to lessen issues on the contributors end if they don't abandon their
contributed branch (in favor of your rebased version) and you only
have to do a single 3-way merge instead of one per commit.

It's also sometimes used for modifying or cleaning up your local
history before you share it, even in a merge-only environment.  For
instance, you can use it interactively to squash down multiple commits
that should be one logical changeset, remove or re-order commits,
transplant topic sub-series, fix poorly considered commit messages,
etc.  You do this all locally, so it looks like you originally knew
what you were doing, then push it upstream.

Some information on rebasing (in Git):

http://progit.org/book/ch3-6.html

and when you might use it in this context:

http://progit.org/book/ch5-2.html#public_small_project

That's all Git-centric, but the gist should be the same. Hope that's helpful.

Scott