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.
- Pushing changes to a Git Repository
- What is a GIT Repository?
- Git Features
- Bare Repositories in Git
- Working with Git Repositories
- Merge Strategies in Git
- Getting changes from a Git Repository
- Git | Working with Stash
- Handling repositories with Git remote
- Using Git on CommandLine
- Working on BitBucket using Git
- Working on Git for GUI
- Using Patches in Git
- Recovering Lost Commits in Git
- Working on Git Bash
- Jenkins and GIT Integration using SSH Key
- Difference Between Git and GitHub
- Using Tags in Git
- What is Collaboration in Git?
- Patch Operation in Git
If you like GeeksforGeeks and would like to contribute, you can also write an article using contribute.geeksforgeeks.org or mail your article to firstname.lastname@example.org. 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.