Git Merge vs Git Rebase

What do I choose? 🤔

merge vs rebase

All of us have heard about git merge and git rebase. But what should I use when, is still a mystery. Let’s understand how each command works.

Let’s say we have a production branch that you created your branch for your feature. You made changes on this feature-branch. Now, you hear there were more changes pushed to production branch. You should have your branch updated to the latest changes before you can continue.

Rebase:

$ git rebase production

How does this work:

$ git switch production
save all the commits done to current branch in a teamporary place
$ git reset --hard HEAD
reset all commits to production branch
re-apply commits saved from temp place one by one. 
if there are conflicts it will show up on your conflicts section. you need to resolve them manually and type
$ git rebase --continue

To understand better — Rebase command will rewrite your commits as if it happened after the branch was updated, including the commit logs.

Merge:

$ git merge production

How does this work:

$ git pull origin production

Very simply nothing is changed in terms of logs, it just tries to merge the origin branch and keeps your original commits. If there are conflicts you need to merge them manually and complete the merge.

Which one to use?

If you are in a Software development team, with multiple developers working with same production branch, Rebase is not a good option. Since it rewrites commit history, you may be affecting branch history for other developers too. If you are the sole owner of the origin branch, then by all means go ahead and rebase.

Merge — does all of the functions Rebase does and it is simpler to use without compromising branch integrity for your team members. My simple advise — don’t play with commit hashes if you don’t have to.