Table of Contents

1. Introduction
2. Git Merge vs Rebase vs Squash
3. My Strategy to choose

Introduction

In this blog, I plan to breakdown differences between git merge, rebase & squash and how to choose which strategy to use for integrating changes from one branch to another.

Honestly, before writing this article I was in the belief that it's always better to use rebase and that you should avoid using merge at all costs.

But I was wrong.

There are some situations where rebasing is a lot harder and sometimes even be impossible (in a reasonable time).

Before jumping into our topic, if you are not familiar with how commits are generated and maintained, Please read this article.

Git Merge vs Rebase vs Squash

In order to fully grasp the difference between these different git methods, Let's go through a journey of commits together.

NOTE: Green Circles represents commits that exists in master before we cut the feature branch. Yellow Circles represents a commit added to master after feature branch is cut. Purple Circles refers to a commit added to feature branch. And Gray Circles refers to a commit added by git.

Consider that you have cut your feature branch from master after it had 3 commits. The History of those branches will look like this:

After some period of time, you have added commits A & B to your feature branch while commits 4 & 5 were added to Master by a member on your development team during the same time period. The branching history will now look like this:

Now, Let’s consider that you want to integrate your feature branch changes into master. Let's go through the strategies of using merge, rebase, and squash to figure out how history looks like

Git Merge

When you use git Merge, it will carry over all commit history from feature branch and will add an extra dummy commit to Master branch.

This is the most common practice followed by developers as it's simple and easy to understand.

But history becomes polluted with dummy commits and debugging using "git bisect" can be harder, especially if master branch is very active.

Git Rebase

When you do Rebase, it rewinds your commits and replays those commits again from the tip of the master branch.
This results in two main changes.

1. Since your commits are now branching off a different parent node, their hashes will be recalculated, and anyone who has cloned your repository may now have a broken copy of the repository. So, it’s not suggested to use rebase to update your feature branch if it is shared with other team members.
2. You do not have a dummy commit, so merge conflicts are identified as your changes are being replayed onto the new tip of master branch, and you need to fix them before proceeding with the rebase.

When you push your changes using rebase, it will look like you wrote all your changes off the very latest commit to the master branch. Here is how Master branch history looks like after rebase

Git Squash

When you do Squash, it’s like Merge except that it doesn’t carry over commit history from feature branch and only dummy commit is created with the title of Pull Request.

Note: There is no command called “Git Squash” if you want to perform squash it has to be used in the combination of either merge or rebase. To know more about how to perform squash refer to this article

Here is how master branch history looks like with "Squash and Merge"

My Strategy to choose

When it comes to Merge vs Rebase vs Squash, I use each of them in different scenarios. Here is how I determine
which git method I will use in different scenarios:

Merge:

1. When I want to update the shared feature branch because in case of rebase hashes will be recalculated which can lead to unintended conflicts while merging changes to master.
2. When I want to update the feature branch that is far outdated from master as resolving the conflicts would be more difficult while rebasing

Rebase:

1. When I want to update the feature branch that's not shared, I will always use Rebase. I do this because I like to keep my branch history clean.

Squash:

1. When I want to merge my feature branch changes to master, I use “Squash” as I will get a single commit for all my changes which is easy to find if I ever want to.

Conclusion:

Be aware, that choosing each of these strategies may depend on you and your team workflow. As you can see, each of these methods have their benefits in different scenarios so take some time to experiment & learn what works best for you.