Rebasing
- We can use a rebasing technique that will result in linear history.
- Using the rebase command, we can change the base of our feature branch, so we can base it on the latest commit on master. We have a direct linear path from feature to master. So if you want to merge the feature branch into Master, we can do a fast forward merge, and now we have linear history. This is called rebasing.
- Rebasing rewrites history, and that means you should use rebasing only for branches or commits that are local in your repository. If you have shared these commits with other people in your team and if you have pushed your changes, you should not use rebasing. Otherwise, you're going to make a big mess.
- When you rebase, the feature branch, Git is not going to change the base or the parent of feature branch, because commits in Git are immutable, they cannot be changed. So Git is going to create a new commit that looks like feature branch commits and apply them on top of Master, then it's going to move the feature pointer over here. Now we don't have any branches or any other commits pointing to feature branch commits. So at some point in the future, Git is going to remove this commit. So we are essentially rewriting history. So if you have shared feature branch commits with others, and other people have created a new commit on top of these. Now, after rebasing, their history is going to get screwed.
git switch feature/shopping-cart
git rebase master
git switch master
git merge feature/shopping-cart
Rebase Options during conflicts
- Continue: tell git to apply the next commit on top of master
- Skip: skip the current commit and move on to the next commit.
- Abort: useful in situations where we have so many commits to apply on top of Master. So this will take us back to the previous state before we started rebasing.
git rebase --continue
git rebase --skip
git rebase --abort
git clean -fd
git config -global mergetool.keepBackup false