Merge VS Rebase: Which Is Better ?

I usually prefer using Merge over Rebase for safety first.

Merge and Rebase are two ways of combining changes from different branches when using GitHub as the chosen source code management platform. Since Merge seems to be enough to get things done in every case, why does GitHub include the Rebase method?

The answer seems related to the team’s preference on the commit history. GitHub maintains a tree of commits per repository, and each commit is a snapshot of all files. It is important to notice that GitHub stores project snapshots, not the diffs that we see with the command git diff. Diffs are calculated on the fly when we compare two commits. This nature of GitHub affects how Merge and Rebase behave under the hood:

1. How does Merge actually work ?

When using git merge to merge branch A into branch B, and given that branch B was created from branch A, GitHub performs the following steps:

1. Finds the common ancestor snapshot, aka the commit where branch B is created from.
2. Compares the latest snapshots of branch A to ancestor snapshot, get the diffs D1 (aka MERGE_HEAD)
3. Compares the latest snapshot of branch B to ancestor snapshot, get the diffs D2 (aka HEAD)
4. Applies diffs D1 & D2 on the ancestor snapshot then output a new merged snapshot, stored in a new commit of branch B

Because commits are snapshots:

• Git doesn’t need to replay all intermediate diffs.
• It just looks at 3 snapshots: ancestor , HEAD and MERGE_HEAD.

That’s why merging large histories is fast and doesn’t rewrite old commits — the snapshots are stable and immutable. When using Merge, if conflicts happen, because there are always 3 snapshots taken into account, the output is always 1 new snapshot; resolving conflicts when using Merge likely happens only once.

2. How does Rebase actually work ?

When using git rebase, for example, to rebase branch B onto branch A, given that branch B was created from branch A, GitHub performs the following steps:

1. Calculate the diff between each commit (aka snapshot) of branch B to its parent commit. This is likely to create a “patch” telling step-by-step how changes are already made on branch B,
2. Reapplies those diffs (patches) on top of latest snapshot of branch A
3. Creates new commits with new IDs (aka new snapshots).

So every time we rebase branch B onto branch A, new commits (or snapshots) are added as if we have just made those changes on the snapshots of branch A. Because diffs are reapplied every time we rebase, if there are conflicts, we are likely to have to resolve the same conflicts again and again. This is why I prefer merge to rebase.

3. So, why does Rebase exists ?

Rebase is mostly used when we have a reason to control how the commit history looks on a branch. This can be useful when a team prefers a linear commit history that is easier to read and does not care about what actually happened, such as when a branch is created and what is merged.

Because it rewrites commit history on a branch, Rebase is not recommended for use on the main branch due to the risk of losing commits and resolving conflicts multiple times. Rebase is safer only on a feature branch, which is created from the main branch, and, most importantly, this feature branch should have a short development time. On a feature branch that lives long enough, re-resolving conflicts might happen frequently, which can slow down development speed and even frustrate developers.

4. Conclusion

In summary, my suggestion on merging vs. rebasing is:

1. Always use Merge for safety first
2. If we are working on a feature branch (NOT the main or master branch) and want to have a nicer commit history on this branch, and the development time for this branch is short, then we can use rebase.

Build – Secure – Evolve with the-tech-lead.com.