DEV Community

Cover image for Git Rebase Explained Simply

Git Rebase Explained Simply

Jacob Herrington (he/him) on January 03, 2020

Rebase might be the most misunderstood git command. Nearly every junior developer I pair with is terrified of git rebase. Ironically, rebase is o...
Collapse
 
murrayvarey profile image
MurrayVarey

I still feel a nervous tension whenever I rebase. It seems to depend on the context. Sometimes rebase feels like the obvious thing to do, other times I just know rebase is going to break everything ... until it doesn't. Basically, git can sometimes be scary.

Loving the series, Jacob. Thanks!

Collapse
 
jacobherrington profile image
Jacob Herrington (he/him)

Git is terrifying. That's a big part of the reason I chose to write about it.

These tools don't have to be scary, and hopefully writing about them in simple terms helps to dispel some of the mystery about them.

Collapse
 
murrayvarey profile image
MurrayVarey

Git is terrifying.

Yup! But I couldn't work without it.

For me, you're doing exactly that. Keep up the good work.

Collapse
 
harkinj profile image
harkinj

Great article. Can u confirm that u would typically pull the master branch (to ensure u have the latest master) before doing a 'git rebase master' as mentioned in article to rebase 'master onto a branch'. Thanks for your time.

Collapse
 
jacobherrington profile image
Jacob Herrington (he/him)

Yeah, generally that would be my workflow. 👍

Collapse
 
ryansmith profile image
Ryan Smith

Good stuff, this is an easy to understand explanation. For me, git rebase was an imposter-inducing concept because a lot of the information out there is so nonchalant ("just rebase") or so technical (a complex web with arrows everywhere) that it was hard to establish when to use it and how in a practical example, so thank you for that.

"Always Sunny in Philadelphia" meme of the character standing in front of an investigation board and a conspiracy-theorist look in his eyes

Collapse
 
jacobherrington profile image
Jacob Herrington (he/him)

Cool, I'm glad it was easy to understand; that was my primary goal.

Which is why the example is so simple (but a common problem nonetheless).

I'll probably do a follow up going over the -i flag and some more creative things you can do with rebase to make your life easier.

Collapse
 
thumbone profile image
Bernd Wechner

I'm one of the many who are nervous about rebase. And while I enjoyed this piece as one of the easier to read and digestible presentations of what is going on, it also exemplifies the source of my discomfort. It creeps into every tutorial I've read to date at some level or another and can be stated in one phrase: presumed knowledge.

That threw me reading this:

  1. What is the chronological order of the commits in your first two branch commit lists? I mean I could conclude (infer that they are most recent at top, oldest at bottom, by making the visual comparison you suggested, but I would still recommend stating it clearly).

  2. When in working-branch (with that branch checked out) you do git rebase master, it is worth stating up front the direction and end result. I infer the direction is that the checked-out branch is being "replayed" onto the branch mentioned in rebase. So that git rebase might be understood as git rebase current branch onto.

But I'm still left puzzled about (and maybe I'm just slow but I give the ubiquity of rebase fear I wonder ...):

a) what happened to the working-branch? Does it still exist, or does it disappear, all its commits now replayed onto master? Again from inference and other reads, I can infer it still exists but the parent of the first commit on that branch is now the head of main,

b) what does "replay" actually mean, if I imagine my commit as a delta then applying that to a new parent commit raises the risk of merge conflicts.

c) if there are merge conflicts, these may take time to resolve, time during which master may have new commits added to it. If working-branch is in fact the only thing being changed (that is important to say if so) and it stays around simply when a new parent then this is inconsequential I guess.

d) what exactly are the risk, what is being changed? I might infer that the whole git rebase master never touches or risks anything on master, only asks that the head of master be the new parent for the current branch and that we adjust the commits (with a merge tool as needed) to make that possible.

e) are there any GUI rebase tools or wizards for people not so comfortable with the CLI

Collapse
 
rhymes profile image
rhymes

I was terrified of rebase too for a long time

I think it's a failure in git's communication strategy 😂

Collapse
 
jacobherrington profile image
Jacob Herrington (he/him)

I agree, it has a bit of a public perception problem. 😬🙃

Collapse
 
uuykay_1337 profile image
William

To be honest I'm still confused. What is the need for rebase, if you can merge master into the working branch?

Collapse
 
jacobherrington profile image
Jacob Herrington (he/him)

For one thing, merging creates a merge commit which can clutter the git history. I don't feel as strongly about that as a lot of people do, but it's the most common argument for rebasing over merging.

Personally, I prefer rebasing because of the -i flag which allows you to re-order commits, reword their messages, squash, and manipulate commits in a bunch of cool ways!

Collapse
 
john2220 profile image
John Raptis

Great post. Explained simply indeed. I can't recall how many times I googled what rebase 'really' does and not just trusting stack overflow. Btw I love your podcast. Keep it up.

Collapse
 
jacobherrington profile image
Jacob Herrington (he/him)

You talked me into it:

Collapse
 
jacobherrington profile image
Jacob Herrington (he/him)

Glad to hear it. Hopefully I get some new episodes up soon.

Collapse
 
mjtredoble profile image
Michael Joseph Redoble

Finally a simple and easy to understand article about git rebase.

At first I was terrified doing rebase but now its my daily habit on maintaining feature branch.

Collapse
 
harkinj profile image
harkinj

Great article. Would u typically do a 'git pull master' to ensure master is up to date before git rebase master? Thanks for your time.

Collapse
 
briankgarland profile image
Brian Garland

Ok, just so I’m clear:
From branch, checkout master.
Pull from origin to get master changes.
Go back to branch.
Run: Git Rebase Master

Like that?

Collapse
 
vberen profile image
Nicklas Wessel

Thanks for sharing :)
I will definitely try to work with this, it makes a lot of sense.

And then I should really get a guy course soon !

Collapse
 
thojest profile image
thojest

this was my third or fourth attempt on trying to understand rebase and the first successful one. thank you!

how can something so simple be so hard to explain?

Collapse
 
jacobherrington profile image
Jacob Herrington (he/him)

I'm so glad to hear that you were able to understand the article!

Collapse
 
sebbdk profile image
Sebastian Vargr • Edited

When i rebase, it's always because your base is belong to me.

git push -f origin master

Collapse
 
jacobherrington profile image
Jacob Herrington (he/him)

alias git-yeet='rm -rf * && git commit -am "yeet" && git push -f origin master'

Collapse
 
bertheyman profile image
Bert Heyman

Love the clear explanation, was the start for me to start experimenting with git rebase.
Sometimes, an article can be the push needed to start - thanks!

Collapse
 
wizarcane profile image
Erik Lim

What happened to commit 'df796f7e Cache data on /mod (#5315) [deploy]' in the working branch (before rebase)? 🤔

Collapse
 
jacobherrington profile image
Jacob Herrington (he/him)

Haha, I just removed it. That was an accident. I was using the dev.to's git repository for the examples and I removed some commits to make them shorter/less tedious to read and I guess I just removed that one everywhere else!