Git 'Merge', or Git 'Rebase', What to Use and When

Which to use? Git Rebase, or Git Merge.

It may not be up there with Android vs iOS or Vim vs nano but rebase vs merge has rallied plenty of debate in particular circles. I’ve personally used both methods within many different projects and teams and over time have figured out my preferred workflow which is something I’m always happy to share, so let’s dive in.

Git Merge

Join two or more development histories together.

Definitely the more popular of the two, git merge is essentially the process of combining a forked history. These forks are the independent feature branches we work on throughout development before being merged into a single branch again, which is more often than not the main working branch, but it can be any feature branch.

Git Rebase

Reapply commits on top of another base tip.

On the other side we’ve got git rebase which will compress all changes into a single “patch”, which is then integrated onto the target branch.

So what actually is the difference?

The main difference between the two operations is that git rebase will flatten history, which is done by placing the new branch onto master. This is unlike git merge which will preserve the history, by adding a new commit instead.

Pros & Cons

Rebase

Pros

A flattened commit history.
Manipulating a single commit is a lot easier.

Cons

Rebase can actually invalidate tests.
Commits may end up out of chronological order.
You’ll need to force push at some point. (Which isn’t a problem, but environments will dictate this)

Merge

Pros

Conflicts can be solved within a single commit.
Traceability with all commit history readily available, maintaining context.
Extremely simple and familiar to most developers.

Cons

Pollution can be a problem on projects with a large amount of contributors.

Personal Approach

What approach you take to using either git rebase or git merge will depend on your working environment and overall what you’re comfortable with.

If you’re working alone, on personal projects, the choice is completely yours of course. If you’re in a professional setting you’ll need to follow the policy in place set by the team or organization. If you’re contributing to open source it’s important you follow the defined contributing guides.

Personally, I rebase when working alone, such as feature branches in an organization, and merge when working with others. That seems to be the general consensus with the debate, rebase for individuals and merge for teams.

How this works in my scenario is that I can work away on a feature branch and rack up commits as normal. When I’m ready to submit a pull request for review, I’ll squash and rebase my work into a single commit. This piece of work contains all the work of the feature, along with a lengthy commit message describing the feature as an entire unit.

    git rebase -i HEAD~[Number of commits]

If this work is acceptable, it will be merged with the main branch the rest of the team are contributing to.

Should changes be needed to my feature branch before acceptance, I can carry them out as normal and again squash and rebase into a single commit, updating the message where needed also. This approach allows both methods to compliment each other nicely, and reinforces the idea of rebase for individuals and merge for teams.

It’s obviously advisable to play around with both operations until you’re comfortable and then see what works for you in your different working environments, there’s just one rule to remember with rebase and it’s called The Golden Rule: