Understanding Git Rebase and Its Benefits

In this article, we will dive into Git rebase and its advantage. What is Git rebase? Git rebase is similar to Git merge whose main purpose is to integrate changes from one branch to another. If git merge does the same, why do we need git rebase? Well, the ultimate goal is the same but they follow a different approach to achieve the same.

The main difference between git rebase and git merge is that git rebase helps to create a linear clean commit history whereas git merge is used to set of commits to be clearly grouped together in history.

To be more specific, merging branches using rebase takes the contents of a source branch and integrates them with a target branch. In this process, only the target branch is changed. The source branch history remains the same.

Benefits of Rebase

One of the benefits of Git rebase is that it prevents a long history of commits in our project. We will discuss it below. As a result of clean history, If we want to roll back our application to a previous version to check where a bug has been introduced we can do that easily.

To give an example of clean history, let’s check at the following example. Suppose, we have a new branch feature and one commit in this branch. Let’s say we want to merge the recent changes from master to feature branch, we may do so by simply running the below command

git merge feature master

It will merge the latest changes to feature branch but also create a new merge commit. If the master branch is active then frequently merging the master branch to feature branch can pollute with unnecessary merge commits. Thus, rebasing can be helpful to keep the commit history clean.

Git Rebase

In this section, we will see how we can implement rebase in our project. We can do so by running the below command:

git checkout feature
git rebase master

//OR
git rebase feature master

What happens when we run the above commands? This moves the entire feature branch to begin on the tip of the master branch, effectively incorporating all of the new commits in master. But, instead of using a merge commit, rebasing re-writes the project history by creating brand new commits for each commit in the original branch as in the below diagram.

I hope this makes the basic concept of git rebase clear. We will follow the article with more deep diving in this topic later.

Note:

We should never rebase commits once they’ve been pushed to a public repository. The rebase would replace the old commits with new ones and it would look like that part of your project history abruptly vanished.