From the standpoint of the end result, a merge and a rebase in Git appear to do the same thing:

A + B + A’ (merge) = A + A’ + B (rebase)

Wouldn’t it be simpler to just choose one operation and stick with it?

The answer of course is no.  Otherwise you wouldn’t have the option.  (If you feel completely contrary, best of luck.  And choose merge.)

It really only becomes apparent once your development effort becomes hierarchical, either in terms of application lifecycle (such as dev, test and release versions) or in a team structure.  You’re now dealing with multiple branches, each with non-trivial changes that can and will occur independently.

Rebases are how changes should pass from the top of hierarchy downwards and merges are how they flow back upwards.

Let’s take a look in more detail at what is actually taking place in each operation for a parent branch A and a child branch B:

Merge

A + B + A’ + dA’B

where A’ are the changes being merged in and dA’B the resolution of merge conflicts from A’ and the set of commits B on the current branch

The changes introduced by A’ and dA’B are grouped together into one merge commit A” = A’ + dA’B that is added on top of the existing set of commits (A + B) and becomes the head of the current branch:

A + B + A”

Rebase

A + A’ + B + dA’B

The rebase resets the starting point the branch and reapplies the set of commits B.  Merge conflicts dA’B are combined with these commits so they become grouped together B’ = B + dA’B:

A + A’ + B’

If you stare at it, you’ll realize that the rebase guarantees that the changes being brought it in from the other branch come in exactly as-is: A + A’.  Any conflicts are resolved and contained with the associated commits B’ on the current branch.

Using merge to pull in changes from the higher-level branch mixes those changes with the resolved merge conflicts.  This means that the current branch won’t necessarily have the same state as the one it was based on (from the hierarchical structure).  And since the resolved conflicts are grouped all together in one merge commit, you’ve also made it harder to cleanly cherry-pick individual changes.

Having development lifecycle tracks and each local developer branch start from known consistent states is critical to reducing and resolving code issues.  Where a change occurs (or suddenly becomes missing) and who is responsible become easier to determine.  By using the rebase to pull in changes, you have that.

When you’re submitting changes back up the chain, you only want to add your changes on top of the existing commits of the higher-level branch.  Merge is clearly the operation for that.

Even if you’re a single developer with only a few branches, it’s worth it to get in the habit of using rebase and merge properly.  The basic work pattern will look like:

1. Create new branch B from existing branch A
2. Add/commit changes on branch B
3. Rebase updates from branch A
4. Merge changes from branch B onto branch A

That’s not a bad thing.  It simply means that it’s not any more or any less than what it claims to be: a distributed version control system.  And it’s very good at what it does.

But once you get beyond the initial repository setup and the standard add/commit cycle, you’re inevitably going to have a few questions:

• How often should I commit my changes?
• When should I create a new branch?
• What do I need to do to share my updates?

And these lead to a few more

• How do I manage all these branches?
• When should I merge the changes from my branches together?
• What’s the difference between a merge and rebase?

If you’re working in a team, you’ll probably also have

• What’s everyone working on?
• Do I have the latest updates?
• When do I submit my changes to the team?

And if you’ve been going for a while, you’ll want to know

• How do I simultaneously manage a release and a development version?
• Did that production fix get back into development?
• What did I just release?

At this point, you’re starting to slip into the realm of software configuration management (SCM).  Version control is just a small part of that.

The bad news is that Git doesn’t say anything about how you should do any of this (FYI, the pull request is more a suggestion than a formal required process even if it’s what Linus does).  It’s also the good news: You have all the technical capabilities you need but you’re not tied to a rigid one-size-fits-all process.

The key thing to remember is that Git isn’t the first VCS tool out there, even if it might be the first one you’re using.  There’s an amazing wealth of SCM knowledge to tap into.  It’s a matter of starting with what works and figuring out how Git fits into that.