Rebasing
Rebasing is literally ‘re’-basing your feature branch, so that it is as if the new base of that branch was always there. This new base may be your the master branch you cloned (branched off of originally) to create your feature branch + some new bug fixing commits that have been made on the master branch since you cloned it (branched off of originally). So you would be rebasing your feature branch so that it looks like the new bug fixing commits were always there. Git achieves this by creating brand new commits that make it look like this is the case. It is only to be used in certain scenarios however, see below for more information.
A useful article:
https://www.atlassian.com/git/tutorials/merging-vs-rebasing
When not to use rebasing?
A rough golden rule of when to not use rebase is if the branch you have checked out when you are trying to rebase is being used by a different sub-branch. e.g Say you want to have a big fix that was created on a branch off the master branch. When you want to combine the changes of the bug fix into the master branch it is normally best to check out the master branch and rebase the master branch onto feature branch. ONE: Even though it would show the feature on the master branch, it doesn’t make much no logical sense in my opinion as it pushes the feature commits happen before any of the master commits, TWO (if working with other people): Any one else working off of the master branch they will now have a different base to the master branch as brand new commits were created. This causes confusion, as stated in the link above: Since rebasing results in brand new commits, Git will think that your master branch’s history has diverged from everybody else’s. The only way to synchronize the two branches is to merge them back together, resulting in an extra merge commit and two sets of commits that contain the same changes (the original ones, and the ones from your rebased branch). Needless to say, this is a very confusing situation.. In these scenarios merge the new feature branch into the master branch instead.
When to use rebasing?
Generally good use case is when incorporating upstream changes from b1 into branch b2 (if no one else has branched off of b2 -> in this case merge). Check out branch b2 and rebase it so it is as if the the new changes in branch b1 where always there in branch b2. Then when you are ready to incorporate the new changes in b2, merge b2 into b1.
Every time you merge it created a brand new commit for that merge so that it is not destructive. But it can pollute your history tree, especially if your upstream branch is frequently being updated. For example if you are merging in from a upstream branch 10 times a day you will have to make 10 merging commits a day. When looking through your git history this makes it harder to see what “useful additional commits” were made on your branch. With rebasing the 10 pollution commits a day would not exist. Therefore in turn rebasing also makes it easier to navigate your project with commands like git log, git bisect, and gitk.
Summary:
Rebasing is a useful tool to improve git history but it cannot fully replace merge in a team that is > 1 developers. For a project with > 1 developers they need to be used together (or if not confident in rebasing then just use merges). If you are working alone then using rebasing in every scenario is less of an issue, but it is still logically best to stick to the golden rule of rebasing.
Top comments (0)