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.