Git Rebase

Rebasing as the name suggests is the process of changing the base or the commit point from which the branch was created. Rebasing is similar to merging because both of them help to integrate feature branches into the master branch or any other branch that we want. In this tutorial, we will learn more about rebasing and how it is different from merging.

What is Rebasing?

• It is the process of changing the base of a branch.

• The initial base of a branch is the commit point from which it originated.

• We don’t always want the branch to be based on that same commit point. There could be some scenarios in which we want to change the base of our branch.

• Rebasing is essentially just a different approach to integrate two branches. By changing the base of a branch we are making that branch aware of the changes that were made to the other branch.

How Rebasing Works?

Rebasing is done by creating new commits for our branch and then updating the base of the branch to the tip of the other branch. Rebasing rewrites the history of commits because after rebasing we can no longer see the commit from which a branch originated.

Consider the following example to better understand the working of Rebasing.

1. Let's assume that we have a master branch with two commits and we create a new feature branch. The branch will be based on the last commit of the master branch.

2. Now suppose that we add two commits to the master branch and three commits to the new feature branch.

3. We can integrate the two new commits of the master branch into the feature branch by running the rebase command. This will change the base of the feature branch to the most recent commit of the master branch.

4. One thing to note is that the previous commits of the feature branch are not shifted but instead new commits are created. But these commits have the same snapshots of the project that were present in the previous commits.

Why Rebasing?

• Rebasing is typically used to either update the feature branch about the new commits of the master branch or to update the feature branch before merging it into the master branch.

• But we have the Git Merge command that can combine the feature branch with the master branch.

• The difference is that Git Merge will combine the changes of the two branches into a single merge commit while rebasing will just change the base of the branch to point to the latest commit of the other branch.

• When we have a lot of developers working on different branches and merging them into the master branch it becomes very difficult to understand the history of commits. In the following image, we can see a lot of branches and merges which makes it very difficult to understand the commit history.

• Rebasing, on the other hand, maintains a linear commit history which makes it very easy to understand the project history.

• Rebasing is also helpful in resolving conflicts because it tells us about the conflict occurring at each commit point. On the other hand, merging tells us about all the conflicts about all the commits at the same time making them difficult to resolve.

Consider the following example which shows the difference between Merging and Rebasing.

When not to use Rebase?

• Rebasing is not a good alternative when working on a shared branch as it may lead to inconsistencies. In most cases, the master branch is cloned by everyone and then new branches are added to work on different features. But if someone rebases the master branch then the history of commits for all the other developers becomes inconsistent.

• Git won’t allow us to push such a branch back to the remote repository but we can bypass that by using the --force flag.

• Rebase is also not preferred when we want to maintain the original commit history as rebase alters the history while merge doesn’t. For example, a developer can know the exact point where he started a new branch and where he integrated it with master if he used merging but cannot do so while using rebasing as the initial base of the branch will be lost and no merge commit will be created.

Git Rebase Command

Git Rebase works in two modes - Standard and Interactive. In standard mode, Git will just accept the Branch that we want our branch to rebase to. However, interactive mode provides us a lot more flexibility and options to work with.

Standard Rebase

The Git Rebase command by default works in the standard mode. We can pass the branch name to which we want to rebase our current branch.

$ git rebase <branch-name>

We can use the --continue flag to continue the rebase process if the rebase was stopped due to a conflict.

We can also rebase some other branch without checking out that branch by passing the names of both the branches(one that we want to rebase and the other branch on which we want to rebase)

$ git rebase <branch-to-rebase> <destination-branch>

Interactive Rebase

• In the interactive mode of rebasing, Git allows the user to do a lot more than just rebasing the branches. We can perform a lot more operations like editing and reordering the existing commits with the interactive mode.

• To invoke the interactive mode of rebasing we need to use the -i flag.

$ git rebase -i

This will open a text editor where you can enter commands to alter the commits.

The following table explains the different options that are provided in the interactive mode.

Summary

Git Rebase is just another way of combining branches. It works by changing the commit point from which the branch originated, hence the name. Rebasing maintains a linear commit history which is very easy to understand. However, we should not use Rebase while working on shared branches as it can create inconsistencies for other developers. Git also provides us with an interactive method of rebasing in which we can modify, reorder, squash, or even delete the commits. I hope this tutorial was helpful and you learned something new.