All about merging and rebasing in Git
Hey folks! I hope its time to bring in the changes, thats why you are here reading my blog. As a beginner you might be afraid of using the
git rebase command as it is known to wreak havoc by rewriting history if not used properly at the correct place. Let me tell you that it can make life much easier for a development team when used with care.
git rebase solves the same problem as
git merge. Both commands integrate changes from one branch into another branch. It’s just that they do it in very different ways. Confused? Don’t be !
Lets consider that you create a new dedicated branch to work on a new feature.
Meanwhile, another contributor updates the master or main branch with new commits. Now, you have a forked history which should be familiar to anyone who has used git as a collaboration tool.
To include the new commits into your branch, you have two options: merging or rebasing.
The Merge Option
Simply merge the
master branch into the
This gives a branch structure that looks like this:
Git internally takes two commit pointers, usually the branch tips, and will find a common base commit between them. Once Git finds a common base commit it will create a new “merge commit” that combines the changes of each queued merge commit sequence.
Merge commits are different as they have two parent commits. When creating a merge commit Git will attempt to automatically merge the separate histories for you. If Git encounters a piece of data that is changed in both histories it will be unable to automatically combine them. This scenario is a version control conflict or a merge conflict and Git will need user intervention to resolve this.
Types of Merge
It can occur if a linear path exists from the current branch tip to the target branch tip. In order to combine the histories Git just has to move(fast-forward) the current branch tip up to the target branch tip.
Scary? Common! It is called a 3-Way Merge as Git uses three commits to generate the merge commit — the two branch tips and their common ancestor. In this case a linear path does not exist between the two branch tips.
The Rebase Option
Rebasing is really just moving a branch from one commit to another. Pulling in upstream changes with Git merge results in a superfluous merge commit every time. On the other hand rebasing is like saying ‘I want to base my changes on what everybody has already done’. Rebase helps to keep your git history cleaner and simpler.
To rebase the feature branch onto the master branch:-
Rebasing is changing the base of your branch from one commit to another making it appear as if you’d created your branch from a different commit. Internally, Git accomplishes this by creating new commits and applying them to the specified base. In this process a temporary branch is created that is a copy of the master branch(here). It’s very important to understand that even though the branch looks the same, it’s composed of entirely new commits. The commits have a new hash but keep their original date which might be a bit confusing since in the final branch the commits in purple are created earlier than the ones in blue. Rebasing is used to maintain a linear project history. After rebasing it appears as if you’ve been working off the latest master branch.Rebasing gives the later benefit of a clean merge of your feature branch back into the master branch. Rebasing is beneficial as it helps in debugging using
git log because of the linear project history.
Golden Rules Of Rebasing
Don’t rebase public history or branches
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 got deleted.
Commiting when remote branch changes
If you commit to a branch, but that branch changes at the same time on a remote machine, you can use rebase to shift your own commits, allowing you to push your commits to the remote repository.
You have two options for integrating your feature into the master branch:
- Merging directly which results in a 3-way merge and a merge commit.
- Rebasing and then merging which results in a fast-forward merge and a perfectly linear history.