DEV Community

Cover image for Git Rebase vs Merge
Juri Strumpflohner
Juri Strumpflohner

Posted on • Originally published at juristr.com

Git Rebase vs Merge

This post has originally been published on https://juristr.com/blog/2019/12/git-rebase-vs-merge/. Go to juristr.com/blog for more content


Git is an "old" technology if you want that has been around for ages now. Still, when speaking or collaborating with other software developers, I always again see them struggle with apparently basic commands. But it doesn't have to be scary. In this article I'm going to quickly walk you through the difference between "merge" and "rebase".

Before starting, if Git is something that sounds interesting to you, where you think you might want to learn more and dig deeper, then I have something for you 😃. A while ago, I recorded a ~30min course on Egghead that walks you through the main commands you need to know to safely use Git on a daily basis. Check out the course here:

Productive Git for Developers

Merge vs Rebase

Other Resources

You're more a "book person"? Then you might want to check out the "Rebase Book" written by my friend Pascal Precht.

Top comments (8)

Collapse
 
ezrahnyanat profile image
Ezrah Nyanat

thanks for posting and making the video! great explanation. seems like git rebase is cleaner and maybe preferred?
what are some example situations when git merge is the better method to go with? (other than the example you mentioned in the video when you're not the only working on a feature branch)

Collapse
 
juristr profile image
Juri Strumpflohner

It's not "cleaner" or "preferred" 🙂. It's another option to "git merge".

Rebasing (for merging) is basically always preferred when you want to have a linear git commit history. On the other side, if you're following branching models like "git flow" then that's probably not what you want, as that strategy suggests to keep merge commits. On the other side, if you're using something like "trunk based development" (trunkbaseddevelopment.com/) then you will.

Now apart from updating feature branches etc, having a linear commit history on the main branch (i.e. master) has helped me a lot for things like "git bisect" to debug problems in a larger git based monorepository.

Collapse
 
victoryarema profile image
Victor Yarema

The trick is that the statement "don't use rebase on shared branches" is just wrong.

Collapse
 
gayanhewa profile image
Gayan Hewa

+1 IMO, the working branch should be rebased against the upstream. But shared branches ie. Master / or anything else similar should have merge commits.

Thread Thread
 
juristr profile image
Juri Strumpflohner

Can you elaborate on that? If I got you right, you basically say that the feature branches should be rebased to be updated with master, but when you merge it back it, you want to use a merge commit, so use "git merge". Is that what you intended?

Collapse
 
juristr profile image
Juri Strumpflohner

What do you mean by "is just wrong"? You suggest using rebase also on shared branches? Can you elaborate?

Collapse
 
reckuza profile image
powered by ቶሎሳ

git rebase is probably my favorite git command currently. It just helps to create a much cleaner commit history.

Collapse
 
juristr profile image
Juri Strumpflohner

Absolutely. The only important thing about rebase is to properly understand it. Especially the thing that it is actually rewriting your history and thus you shouldn't do it on shared branches etc :)

But once you get past that, it's pure power 🙂