Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Git Merge vs. Rebase

DZone's Guide to

Git Merge vs. Rebase

Git merge and rebase serve the same purpose - they combine multiple branches into one. Which should you use?

· DevOps Zone ·
Free Resource

Learn more about how CareerBuilder was able to resolve customer issues 5x faster by using Scalyr, the fastest log management tool on the market. 

Git merge and rebase serve the same purpose - they combine multiple branches into one. Although the final goal is the same, those two methods achieve it in different ways. Which method to use?

What Does Merge or Rebase Mean?

Here we have a sample repository that has two diverging branches: the master and the feature. We want to blend them together. Let's take a look how these methods can solve the problem.

Merging

When you run git merge, your HEAD branch will generate a new commit, preserving the ancestry of each commit history.

Fast forward merge is a type of merge that doesn't create a commit, instead, it updates the branch pointer to the last commit.

Rebasing

The rebase re-writes the changes of one branch onto another without creating a new commit.

For every commit that you have on the feature branch and not in the master, a new commit will be created on top of the master. It will appear as if those commits were written on top of master branch all along.

Merging Pros and Cons

Pros

  • Simple to use and understand.
  • Maintains the original context of the source branch.
  • The commits on the source branch are separated from other branch commits. This can be useful if you want to take the feature and merge it into another branch later.
  • Preserves your commit history and keeps the history graph semantically correct.

Cons

Rebasing Pros and Cons

Pros

  • Code history is simplified, linear and readable.
  • Manipulating a single commit history is easier than a history of many separate feature branches with its additional commits.
  • Clean, clear commit messages make it better to track a bug or when a feature was introduced. Avoid polluting the history with 20+ single-line commits!

Cons

  • Lowering the feature down to a handful of commits can hide context.
  • Rebasing doesn't work with pull requests, because you can't see what minor changes someone made. Rewriting of history is bad for teamwork!

You need to be more careful with rebasing than when merging.

Which Method to Choose?

When your team uses a feature based workflow or is not familiar with rebase, then git merge is the right choice for you:

  • It allows you to preserve the commit history for any given feature while not worrying about overriding commits and changing history. It helps you avoid unnecessary git reverts or resets!
  • Different features remain isolated and don't interfere with existing commit histories.
  • Can help you re-integrate a completed feature branch.

On the other hand, if you value more a clean, linear history then git rebase may be most appropriate. You will avoid unnecessary commits and keep changes more centralized and linear!

If you rebase incorrectly and unintendedly rewrite the history, it can lead to serious issues, so make sure you know what you are doing!

Find out more about how Scalyr built a proprietary database that does not use text indexing for their log management tool.

Topics:
git ,git merge ,git rebase ,devops

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}