Git Rebase VS Merge VS Squash: How to choose the right one?
Tags: github, programming, versioning
Published: 2022-07-28 17:57:32


## Table of Contents

1. [Introduction](#introduction)
2. [Git Merge vs Rebase vs Squash] (#merge-rebase-squash)
3. [My Strategy to choose] (#my-strategy)

### Introduction <a name="introduction"></a> 

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](https://www.atlassian.com/git/tutorials/saving-changes/git-commit#:~:text=The%20git%20commit%20command%20captures,you%20explicitly%20ask%20it%20to.).

### Git Merge vs Rebase vs Squash <a name="merge-rebase-squash"></a> 
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:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kd80g0r1yy9k1w45np0d.png)
 

 

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:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/v2ig5tz7iudc3yew797c.png)
 

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](https://git-scm.com/docs/git-bisect)" can be harder, especially if master branch is very active.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mjkulx99wss14rnovai5.png)
   
 


#### 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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/phnpcdhx34qraqtv9jdy.png) 



#### 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](https://www.git-tower.com/learn/git/faq/git-squash)

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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/grqinog3h2hujkrd3ux7.png)
 

### My Strategy to choose<a name="my-strategy"></a> 

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.