> > 2) Suppose I have master branch and topic branch. During my work I am
> > constantly doing "git rebase -i origin/master" down to my topic
> > branch. When I want to merge my Topic branch back to master, should I
> > do REBASE or MERGE? Why?
> Both, I would think. Rebase so your work is against the latest commit on
> master, and then merge it to master to make it available.

It's true that if you're going to rebase it, you'll also have to merge
(you're putting topic onto master, then fast-forwarding master up to
it).  I think the question was more whether or not to rebase at all.
(Maybe you were answering 'yes' and leaving off the 'why?')  There's
not really a single answer to that question.  Generally, rebase is
favored when possible, since it makes the history a lot cleaner, and
just costs a few more seconds of your time.  The strongest reason you
wouldn't rebase is that a commit on the branch has been published
publicly - for example, maybe to finish your topic you had to merge a
public unstable branch into your topic.

However, consider an alternate general workflow: most commits are not
made directly to master, merged branches have descriptive names, and
merges have good commit messages, something like:

    Merge branch 'dev/feature-epsilon'

    * dev/feature-epsilon
      Add feature epislon
      Remove no longer needed feature delta

This way, when you look at the history of master with git log or gitk,
you can use the option --first-parent to see a very simplified history
- just all of the topic merges, each with a summary of what it
contains (though it might actually be many commits).  This is what
git.git does.  (It's not even much work - the list is just subjects of
commit messages from the merged branch.)  So while the full history
gets pretty messy, the --first-parent view of history is not only
simple by definition, but is also condensed into neatly summarized
chunks. If you'd rebased all these, you'd always have to look through
every single commit.

So, think about what you want the history of your project to look like
and pick the balance you like - or if it's managed by someone else,
just go with the flow.



You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-us...@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to