how does git rebase work and how it’s different from git merge

git rebase is the command that beginners should stay away from!. Once you completely understand git workflow of our project, then you can use it very often. git merge is used more often than git rebase, but both does the same work, except the history of commits in your remote branch or our git log. Let’s get deep into it. 🙂

Short version

Merge takes all the changes in one branch and merges them into another branch in one commit.
Rebase says I want the point at which I branched to move to a new starting point.

Let’s begin with building a new feature from the master branch. So we create a new branch cool-feature from master.

demo-app (master)$ git checkout -b cool-feature
Switched to a new branch 'cool-feature'
demo-app (cool-feature)$

Now we work on the new feature on cool-feature branch and say we have made new 3 commits, commit_1, commit_2 and commit_3. But at the same time, one of our developer made some major change on master branch with 2 commits commit_4 and commit_5.

Now we need to update our cool-feature branch from master. We have two ways of doing it. git merge or git rebase.

git merge

demo-app (master)$ git checkout cool-feature
Switched to the branch 'cool-feature'
demo-app (cool-feature)$git merge master

This way a new dummy commit is added. The commit_4, commit_5 is combined into one commit. We do not know what exactly were done in commit_4 and commit_5 separately as it’s combined into one commit. We cannot view it in remote branch as well as in our git log.

git rebase

demo-app (master)$git checkout cool-feature
demo-app (cool-feature)$git rebase master

and then merge it in master:

demo-app (cool-feature)$git checkout master
demo-app (master)$git merge cool-feature

This time, since the cool-feature branch has the same commits of master, the merge will be just a fast-forward. The commits commit_4 and commit_5 can be viewed separately in remote branch or git log.

But please make sure you know Golden rule of Rebasing before using git rebase.

The Golden Rule of Rebasing

Once you understand what rebasing is, the most important thing to learn is when not to do it. The golden rule of git rebase is to never use it on public branches.

For example, think about what would happen if you rebased master onto your feature branch:

Rebasing the master branch

The rebase moves all of the commits in master onto the tip of feature. The problem is that this only happened in your repository. All of the other developers are still working with the original master. 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 master 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.

Note:

Beginners who have no proper understanding of workflow of a project should not these 2 commands:

demo-app (master)$ git rebase
demo-app (cool-feature)$ git push origin cool-feature --force

1. Until you know Golden rule of rebasing never use it.

2. Please be careful with --force or -f when pushing to your remote branch. This is Force push. It would remove all older commits and replace your commit which is disastrous. All the other commits would just vanish by –force push!. Always pull the latest code from the branch and make a push, shown below.

demo-app (cool-feature)$ git pull origin cool-feature
demo-app (cool-feature)$ git push origin cool-feature