Caution on Rebase : How Come That Unexpected Commit?

I love rebase, and has it as a prefered way to ensure that the code is synced between people in my team. Rebase, may be hard for someone, but once you understand its mechanism, it makes a lot of sense and returns to you the beautiful and maintainable code.

Today, I would like to demonstrate one use case when rebase may introduce you the unexpected commit.

Consider this repository:

The feature/webboard branch is not up to date as there is one commit ahead in master branch. By taking the rebase as a sync strategy, you have to update feature/webboard by checking it out, then use git rebase master

Every things look fine. However, you soon realize that the commit 3294a70 is not needed.

Thus, you go back to master branch and do git reset --hard HEAD~1 and have that commit removed successfully.

Again, when the parent branch is changed, you have to rebase your feature branch accordingly. Here, we need to rebase feature/webboard on master.

It is sure that the rebase will be passed without any conflict, as feature/webboard branch is already on top of master. Unless you come back to look at the result tree.

The commit 3294a70 is still there!!! How come!?!?! you already rebase your branch with master. This commit should disappear!

Thing will go worst if you did not take a look at the tree and merge feature/webboard to master right away.

Many people do merging in a reckless manner and then end up having this problem.

Let’s come back to the question. Why does 3294a70 is still there? To answer this, you have to look back on feature/webboard when it is first rebased. As rebase means to reset your branch on to the parent branch, and re-apply the commits in the branch again. Thus, 3294a70 becomes a part of feature/webboard’s commits. When 3294a70 is removed from master, it is still kept by feature/webboard. So when feature/webboard is rebased again, 3294a70 is re-apply as a member of feature/webboard’s commit.

This problem can be solve by carefully watching at the result tree everytimes the rebase occur. It is not hard to spot, and once you spot it, you can simply use git rebase -i to remove such extrac commit.

Remember, git is not hard as long as you know what you are doing and what are going on according to each action. By caring the result of your tree all the time, this problem can be prevented.

Comments