Git Rebase vs Merge: Workflow and Example

Are Included


In this video you will learn on example the difference between git rebase vs merge and understand why using merge is always preferable. A lot of people like to use git rebase because it makes our history linear but it has lots of pitfalls. I will also show you the correct workflow using git merge. It's super important to understand merge and rebase if you are working with git and secondly people like to ask this question on interview because it shows how deep your skills in git are.

Introduction

Hi I'm Oleksandr Kocherhin from monsterlessons-academy, where I'm teaching you how to become a developer or improve your skills of being a developer in learning by doing way. And if you are new here don't forget to subscribe and I will link everything that I'm mentioning in the description.

Let's jump right into it.

Content

So here is fast and easy solution - just forget about rebase forever, always you merge and you will never ever have a problem.

And I will see you in my next video. Just kidding.

But actually what I said previously is valid solution. Now let's check on the example whats the difference between merge and rebase.

Here we have 2 commits in master branch. First commit was

const a = 'a'

and second commit was

const a = 'a'
const b = 'b'

This is how to commit tree looks like.

Now our first developer decided to create new brach to make more changes and added there one more line

const a = 'a'
const b = 'b'
const c = 'c'

Here is how our commits look like

After this another developer decided to change b variable in master branch

const a = 'a'
const b = 'bbbb'

This is how our commits tree looks. So now in master we have bbbb and in our feature branch c line which doesn't exist in master.

So here comes the question how we can merge changes from one branch to another. Let's say that we want to merge master in feature branch to get the last changes.

To do this we normally write while we are in feature branch

git merge master

If there were new commits in master after we created feature branch than git with create an additional merge commit with last commit from master and last commit from feature as it's parents.

This is how it looks like in the tree.

Why it is good? We didn't rewrite any history, we kept whole representation of what we did and we can debug what happen in git until any commit or change.

However git created an additional merge commit which made our history not linear. For me it's completely fine and it doesn't bother me.

But some people want to have linear history and are using rebase for that. Let's check what rebase is doing.

git rebase master

This is how history is looking now. As you can see it's a linear. But the problem is here that in order to do that rebase takes all commits from master and simply applied feature commits on the top. And it can't be done without rewriting git history because we had in history previously 2 commits from master and then first commit from feature. Now we have all commits from master first which means that we rewrote history.

Is it bad? Yes it's super bad. If you already pushed your code somewhere in github and you will try to push again with rebase git will say you that you history is not equal so you need to push with force to overwrite history tree completely. But you did that only in feature branch and in master you still have old history tree.

Some people are saying "It's fine I'm working on feature alone" and so on but if somebody took your pushed branch before you do the rebase than you will also have different history.

And now the point which really shows that you fully understand the difference between merge and rebase and this is the most important thing between 2 of them. Merge has context and merge information because it has merge commit and rebase doesn't because you simply have a line of commits. So it is possible that you see some code that doesn't make any sense because the context was lost and you don't see what created this changes. You see only the commit.

So what to do to avoid problems? Just stop caring about linear history, stop using rebase and of course stop rewriting history. I never ever use rebase and it never stopped me from being productive. When you want to get master changes in your feature branch just write

git merge master

if you are finished with feature branch just merge it in other direction

git merge feature

This is also super important because it will create a merge commit. Which means if master is broken you can revert merge commit in master and all commits related to feature branch will be reverted.

Call to action

I hope that this video helped you to understand whats the difference between rebase and merge and well as why merge is better.

And luckily I have a git course so go check it our. I will link it down below. Also if you want to learn more don't forget to check my full courses regarding different web technologies. I will link them down in the description box below.

If you find this video helpful, don't forget to subscribe to this channel and hit subscribe button. And I see you in my next video.

🚨 Important