Git rebase vs merge – is there any difference?

In this article we want to have a look at two common git command – git rebase and git merge. We will see how these two commands work and how we can use them.
The main problem here is that both commands can be used in many different situations on project in plenty of different states.

Branching

In both cases we need a starting point. In each development process with GIT there is always situation when we have more than one branch. Besides master we usually have release branches, bugfix/hotfix branches and feature branches. The last one you will probably merge/rebase more often. So, let’s assume we created new feature branch feature-1 from master, commit few things and we want to combine these two branches together again. But in a meantime someone else also developed few things and now there are on master. Current situation looks like:

We have two options on how to do it now: merge or rebase. With both we obtain the same result. The main difference here is how this result is achieved.

Git merge

In a few words: by merging our feature-1 to master we are creating new commit. Merge commit contains every change that has been made on feature branch since it branched from master. If we have any conflicts we should resolve it during merge and after that there will be included in merge commit also.

Our flow will look like:

Git rebase

We can understand rebasing as a moving the base of our feature branch onto a different position – in this case we are moving base from one commit in master to two commits forward:

After that we can simply do fast-forward merge to move label master two commits forward – to the last commit with our feature branch label. Now our master is also up to date:

How not to rebase

You should remember the most important rule of rebasing: never use it on public branches. Because of on public branches other people can work at the same time if you rebase that branch they’ll lose synchronization. So the best scenario when to use rebase is your local development, before you push your changes to public repository.

Pros and cons

Let’s start from rebase. If you decide to use rebasing your code history will be flat and readable. Your commit messages can be clear but it needs some discipline – it’s important not to pollute history with many commits for a single feature or bug fix. It also allows manipulating a single commit very easily. From cons: rebasing can be dangerous – we mentioned that before! Rebasing also doesn’t play well with pull requests.

On the other hand merging helps to keep information about all the changes made in feature branch. But your history can become very polluted by tons of unnecessary commits, and your git charts will be looking like rainbow:

By the way – have you tried to import your git history to Guitar Hero?

Conclusion

If you want a clean, simple history you should use git rebase instead of git merge. On the other hand, if you prefer to save complete history of your project or you are operating on public branches, you should choose git merge. Both options can now be used by you in the most appropriate situations.