DEV Community

ELI5: Git Rebase vs. Merge

Kara Luton on May 09, 2019

Up until now, I had only merged branches into one another but recently I discovered another option -- rebasing! Rebasing and merging are essentiall...
Collapse
 
tonymet profile image
Tony Metzidis • Edited

I'll quote Jesus himself on this. Both points are equally important



People can (and probably should) rebase their _private_ trees (their own 
work). That's a _cleanup_. But never other peoples code. That's a "destroy 
history"

--linus ca. 2009
Enter fullscreen mode Exit fullscreen mode
Collapse
 
karaluton profile image
Kara Luton • Edited

Totally agree. This post wasn’t meant to persuade people to use one or the other just explaining the differences since they are so similar!

Collapse
 
tonymet profile image
Tony Metzidis

You did a good thing. Honestly merge is abused and results in sloppy histories. I put --ff-only in my gitconfig to prevent accidental merge bubbles.

It's good for people to get more comfortable rebasing and pay attention to keeping the log clean--especially on larger teams

A final note--its best to rebase -i before pushing

Thread Thread
 
misterhtmlcss profile image
Roger K.

What does your final note do?

Thread Thread
 
tonymet profile image
Tony Metzidis

Rebase -i let's you squash and amend commits

Collapse
 
detinho profile image
Marcos Vinícius da Silva

It's always good to point out the consequences of got commands that rewrite history, so people are aware of it.

Collapse
 
ssimontis profile image
Scott Simontis

You forgot to mention the golden rule! If the working branch is public (someone besides you has a copy of it), please don't rebase!

Collapse
 
jamesthomson profile image
James Thomson

Came here to say this. If you rebase a public (shared) branch, the other devs working on it are going to be very upset with you. You can rebase all you want while the branch is local, but the second you push it you have to go back to merging.

Collapse
 
misterhtmlcss profile image
Roger K.

So if I fetch origin/master to my local origin/tired branch then I could rebase it. Work on the branch and when I'm done later in the day I can push to GitHub to origin/tired and make a PR to origin/master?

Thread Thread
 
karaluton profile image
Kara Luton

That’s correct!

Thread Thread
 
lane32x profile image
Jon Lane

I think the phrasing of this question could use some clarification.

A good general rule is not to rewrite history (any history) after it has been pushed to the shared repo.

Which means that when you are rebasing in your local repo, you’d only want to rebase your newer commits that haven’t been pushed yet.

Collapse
 
kdraypole profile image
Kobe Raypole

When I was first starting out in development, one of my mentors told me that rebasing is rewriting git history. Whenever you rewrite history you must take extra precautions, It can be very easy to mess things up.

But it is a very important skill to have in order to GIT good :)

Collapse
 
karataev profile image
Eugene Karataev

I might be miss something, but I always merge.
What is the point of having two tools doing almost the same thing? One of them is potentially dangerous and might screw the work if used in a public branch.

Rebase allows to have a clean linear history.

Well, I guess it's personal, but I don't mind merge commits. In our company we usually have max 3 developers working on the repo at the same time, so the git history looks well readable. But I suppose that for the project with 20 developers the git history with merge commits everywhere would look like a mess.

Clean commit messages + amending if necessary + merge - this is all I need.

Collapse
 
lazzu profile image
Lasse

It's not about how it looks like. Rebasing allows backtracking to specific commits when hunting bugs. It makes git-bisect a very powerful tool for pin-pointing buggy commits. When you know which small commit introduced the bug, you are able to fix it more quickly. This is also why smaller commits are way better than large commits.

Collapse
 
karataev profile image
Eugene Karataev

It's possible to backtrack to specific commits and git-bisect with merge as well.

Collapse
 
tcelestino profile image
Tiago Celestino

I used to rebase in my personal projects because I am controlling my code and git push —force isn’t a problem. At work, I prefer use to merge because I think few dangerous use that project that everybody is writing code.

Collapse
 
bulfonjf profile image
bulfonjf

Hi! I'm confused. I can create a feature branch, push it, and do rebase (thinking that is my branch) or I have to follow the golden rule in this case too?

Collapse
 
idanarye profile image
Idan Arye

Private/public, in this regard, is not about who can see the branch but about who is going to work on it.

If only you push to that feature branch, and others are only reading it to review your code, then it's safe to rebase it. Your peers will not lose their work due to your rebase because they don't have any work inside that branch (except from commits it shares with master, of course).

If more developers other than you have pushed to that branch, you can still rebase - but you have to coordinate the rebase with them to make sure you don't lose any of their work. If there aren't that many of them, and if they only pushed to that branch one specific commit that you have personally requested from them (e.g. - you needed something that's out of your expertise), then it's easy. But if many developers are constantly pushing to that branch, coordinating a rebase becomes much harder, much riskier, and with much more damage potential - so it's best to avoid it and just merge.

Collapse
 
bulfonjf profile image
bulfonjf

Thanks! 😊

Collapse
 
vycoder profile image
yev

I personally prefer rebase but only on my local/feature branch before it gets merged to master.

I like to commit as often as I like but I only want one coherent commit message on the master branch.

Collapse
 
karaluton profile image
Kara Luton

Definitely! This is my preferred workflow as well.

Collapse
 
timothymcgrath profile image
Timothy McGrath

I basically always rebase if I'm moving changes away from master, and I merge towards master. Unless I'm on a shared branch, then I always merge...

Collapse
 
karaluton profile image
Kara Luton

Same here!

Collapse
 
wichopy profile image
Will C.

I rebase on my feature branches through development and right before merging so in the history it looks like i branched off the latest master and merged. This makes it easy to see branches in isolation.

If your place of employment does not enforce some sort of git style rules, this will throw your tidiness out the window.

Collapse
 
lukewduncan profile image
Luke Duncan

Great Article Kara!

Pretty much the same as everyone else. Rebase up until I push it into the public sphere, then I go to merging.

Collapse
 
karaluton profile image
Kara Luton

Thanks so much, Luke!

Collapse
 
empreintes profile image
Julien Appéré

for good habits i merge all the time.

Collapse
 
ysakhno profile image
Yuri Sakhno

Squash

Collapse
 
pabloolvcastro profile image
Pablo de Oliveira Castro

Hey forgive me if this question is too newbie, but if you have to do a PR revert (not a GitHub way) it is more easy when you have a merge commit, isn't it?