Rebasing of branches in Git

Branching means to split from the master branch so that you can work separately without affecting the main code and other developers. On creating a Git repository, by default, we are assigned the master branch. As we start making commits, this master branch keeps updating and points to the last commit made to the repository.
Branching in Git looks like this:


Rebasing in Git is a process of integrating a series of commits on top of another base tip. It takes all the commits of a branch and appends them to commits of a new branch. Git rebasing looks as follows:

The technical syntax of rebase command is:

git rebase [-i | –interactive] [ options ] [–exec cmd] [–onto newbase | –keep-base] [upstream [branch]]

The main aim of rebasing is to maintain a progressively straight and cleaner project history. Rebasing gives rise to a perfectly linear project history which can follow the end commit of the feature all the way to the beginning of the project without even forking. This makes it easier to navigate your project.

Standard v/s Interactive Rebase

Git rebase is in interactive mode when the rebase command accepts an — i argument. This stands for Interactive. Without any arguments, the command runs in Standard mode.

In order to achieve standard rebasing, we follow the following command:

git rebase master branch_x

where branch_x is the branch we want to rebase

The above command is equivalent to the following command and will automatically take the commits in your current working branch and apply them to the head of the branch which will be mentioned:

git rebase master

Whereas, in Interactive rebasing, you can alter individual commits as they are moved to the new branch. It offers you complete control over the branch’s commit history.
In order to achieve interactive rebasing, we follow the following command:

git checkout branch_x
git rebase -i master

This command lists all the commits which are about to be moved and asks for rebasing all commits individually and then rebase them according to the choices you entered. This gives you complete control over what your project history looks like.

Merging v/s Rebasing

Both merge and rebase are used to merge branches but the difference lies in the commit history after you integrate one branch into another. In Git merging, commits from all the developers who made commits will be there in the git log. This is really good for beginners cause the head can be rolled back to commit from any of the developers. Whereas, in git rebase, commit from only a single developer will be stamped in the git log. Advanced developers prefer this cause it makes the commit history linear and clean.
The command for merging is given as:

git merge branch_x master

This creates a new commit in the merged branch that ties together the histories of both branches, giving you a branch structure that looks like this as opposed to rebasing what we saw above:

Note: After performing rebasing, we are by default on the last commit of the rebased branch.

My Personal Notes arrow_drop_up

Check out this Author's contributed articles.

If you like GeeksforGeeks and would like to contribute, you can also write an article using or mail your article to See your article appearing on the GeeksforGeeks main page and help other Geeks.

Please Improve this article if you find anything incorrect by clicking on the "Improve Article" button below.

Article Tags :


Please write to us at to report any issue with the above content.