GIT

Differences Between Git Merge and Rebase

Regardless of which branching strategy your project is using, integrating code changes between branches is something that you need to do almost daily. With git there are two main options for this, either you merge, or you rebase.

In this post, I’ll illustrate and highlight the differences between the two options and point out things to look out for when performing the actions.

First, I’ll go through the two operations in isolation using animations, finishing with a side-by-side comparison. If you know how the actions work, feel free to skip to the comparison section.

Reading the official Git manual states that rebase "reapplies commits on top of another base branch”, whereas merge "joins two or more development histories together”. In other words, the key difference between merge and rebase is that while merge preserves history as it happened, rebase rewrites it. Before we look at their inner workings to understand what this means, let’s start with an example! Looking at the example above, we see that the developers Ada and Satoshi initially created two topic branches (feature-1 and feature-2), stemming from the same commit (C1) on the master branch. Ada then completed feature-1 by merging it into master (creating merge commit C4). Satoshi now has two options to integrate Ada’s changes into his branch feature-2 — merge or rebase.

Merge

Let’s start with the most common workflow for integrating changes: merge. Before Satoshi is ready to merge Ada’s changes into feature-2, he must first update his local master reference, as it’s currently trailing behind. Once master and o/master are in sync, Satoshi is ready to merge everything into his topic branch.