Episode: 2573
Title: HPR2573: Foundations of git rebase
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr2573/hpr2573.mp3
Transcribed: 2025-10-19 05:55:53

---

This in HPR episode 2,573 entitled Foundation of Git Remaze and is part of the series version
control.
It is hosted by Klatu and in about 20 minutes long and Karima clean flag.
The summary is Klatu talks about Git Remaze.
This episode of HPR is brought to you by archive.org.
Support universal access to all knowledge by heading over to archive.org forward slash
Donate.
Everyone, this is Klatu.
Thanks for listening to Hacker Public Radio.
This is another entry into how to use Git series and this time we're going to talk about
rebasing.
Re-basing in a way is a special kind of emerging.
In the previous episode we talked a lot about Git head and how Git branches were sort
of floating objects and Git head was this sort of fixed point in time and stuff like
that.
So hopefully you're pretty familiar by now with branches and you're familiar with the
idea that branches get merged typically into other branches very frequently they get
merged into master, the master branch.
A Git rebase is like a merge except that instead of just merging the current state of a branch
so the head of a branch into your target let's just arbitrarily say it's master because
that is very frequently the use case.
So rather than just merging head into master which is usually what a merge does rebase
replays the branch that you have created and worked in on top of the master branch.
That may not make a whole lot of sense to you that's a bunch of special terminology that
relies on you sort of imagining Git in a certain way.
So what I would like to do is kind of go through some examples here and the best way to do
that I think to really highlight what this what Git rebase is at least in my experience
most often used for and that's why I know means saying that this is like what everyone
uses it for and why it's important and stuff like that.
I'm just saying at the jobs that I've had this is how it has been used and this is why
it has been beneficial.
It's really I want to emphasize that rebasing is just basically it's a merge.
I think technically a three way merge because it's taking divergent things and getting
diffs and then replaying it into one but anyway it's just a merge and the end result of
a rebase and a merge is the same.
Like if you if you just look at the most recent state of a of a branch that has been rebased
and the same copy of that branch that has been merged you would be very unimpressed.
It would be the same thing and you would be kind of yeah you'd be non plus you would
not really be that excited about having discovered rebasing where where rebase really makes
a difference is the the project history and this is kind of why it's a little bit controversial
because people people get very nervous if you tell them hey rebasing changes history.
That sounds really bad.
In my experience it's not really bad but I guess it depends on what your goals are.
So let's let's go into the Alice directory in my hpr get folder and I'll create a little
delimiter for us so that I can figure out where this episode's actually started.
So I'm just going to echo foo into zero one dot txt pending it and then I'll do a get
add and then get a commit and I'll put begin get rebase episode.
That way I have a visual line in the sand as it were and I'll even get push this so
that when I inevitably have to do this over a couple of times to get it right I have that
to start with okay.
So what we'll do is we'll so right now if you look at our branch our master branch
in Alice the the top most commit is seven fd 2173 begin get rebase episode great.
So that's that's that's where we are in history that's our head.
Now if we do a get check out dash b experiment that creates a new branch and it branches
off of seven fd 2173 begin get rebase episode and I can confirm that if I do a get log dash
one line it shows me that the top most commit is exact so the history is exactly the same
as the master branch pretty much that's well not pretty much it is it's exactly that's
that's my point is that there is no difference between the history of experiment and master
at this stage.
So let's remedy that let's make these things very different.
So I'm going to echo let's do monsters in this one and then we'll do heroes in the
other.
So we'll do an echo goal echo echo into zero three well actually I guess I might as
well just name them okay so goal dot txt and then I'll do echo well actually and so so
then I'll get add goal dot txt and I'll commit and my message will also just be the word
goal GHOL and so now if I do a get log really quick yet top one on experiment is goal.
So now I'm going to check out master master and get log of course does not have that it's
begin get rebase episode so I'm going to do and I'm going to do an echo of rogue and
I'll put that into a file called rogue dot txt and I'll get add that and I'll get commit
with a message of rogue and now I'm going to get check out now what I'm trying to do here
experiment is I'm trying to emulate and I'll do echo dragon into dragon dot txt and then
I'll get add and commit now I do believe it or not I do want you to remember try to remember
the order that we're doing all of this and so I'm switching back and forth between branches here
I'm doing the monsters in the experiment branch and I'm doing the hero types the classes
rogue and paladin in the master branch and it's important I'm doing one each one after
another so I'm doing goal and then switching and then doing rogue and then switching and then
doing dragon and then switching and doing paladin I mean there won't be a quiz on this later
but it will it will become important go paladin into paladin dot txt so what I'm trying to do
here is I'm trying to emulate people working on projects at the same time and that's kind of
important the rebasing and even merging to some degree but rebasing becomes more important the more
activity you have in your project personally I don't think I've ever rebased my own stuff when
it's just me there's no there's almost no reason to do a rebase then but when you get a lot of people
working on a project and it starts to kind of get messy then it becomes a different story okay so
I've got I've got I've got two different logs now I've got paladin and rogue and then begin
get rebase episode that's in my master branch and then I'm going to check out experiment
and do a log review there and drag in goal and then begin get rebase episode okay so those are
two separate branches with with very different histories they do have a common
beginning point right they begin at begin get rebase episode that's where I branch off of
but but from there they diverge they diverge very sort of clearly so I'm going to back out now
and I'm going to copy recursively and verbosely Alice to Alice-merge and then I'm going to do that
again to Alice-base and so that's just so that I don't have to undo stuff when I when I inevitably
show you two different methods of of bringing these things together so I'm going to do a get checkout
this is my merge okay so get checkout master get logged there's my paladin and rogue and then
begin get rebase okay so I'm just going to do what what one would normally do is get merge
experiment okay so I get right away I get a pop up window a little emax window because that's
what I have my visual editor set to and it says merge branch experiment that's pretty much
what I want to do so copy or I mean I'll save and close that and then it says two files changed
to insertions create mode create mode okay whatever so get log dash dash one line here's
what my history looks like right now so it's merge branch experiment that's what I just did
and then paladin dragon rogue ghoul begin get rebase episode okay so I've got if you've noticed
I've got a merge branch experiment that's that's the that's the the act of merging the branches
and then I've got paladin and then dragon and then rogue and then ghoul which if you'll recall if
you rewind or listen to this in reverse that's the order that I did the those those things in I did
I did ghoul on one branch and then rogue and then dragon and then paladin then I merged now I'm
going to cd into slash dash dot dot slash Alice base and I'll do a get checkout of master so of
course if I do a get log here I will see that I'm back to the beginning I've got my or not
beginning but I've got I'm back to the Alice state so paladin and rogue and then begin get rebase
episode so now if I do a get rebase experiment notice I'm not doing a get merge I'm doing a get
rebase of experiment now what that does is and it tells me this it says first rewinding head
to replay your work on top of it applying rogue and paladin so now if I do a get log dash dash
one line here's what I see in my history I have paladin rogue dragon ghoul and then begin get rebase
so the differences that we can notice here I'll bring them both up on my screen
get log dash dash one line so the differences that I'm noticing here is on the get log of the
rebased repository I've got paladin rogue dragon ghoul begin now on the get log of the merge
repository I have merge branch experiment paladin dragon rogue ghoul so there are there there's
one big obvious difference and that is that you don't get that merge message and honestly when
you have like 10 different people probably even more in some cases but I've never been at a place
where they're you know more than let's say 10 developers actively working on on the on some
program so when you've got that and you and you're eliminating the merge branch of whatever
that's actually worth a rebase for me right there that's honestly it just takes out so much
craft by by eliminating those obligatory merge clatu dev merge bob dev merge Alice dev you know
you've got all these things and and it becomes very redundant especially if you see them every three
lines so that for me is worth a rebase right there but the other thing that you might notice is that
this the the rebase sort of does what it sounds like it's doing if you think about what a base is
so a foundation for instance you remember at the beginning of this episode we branched off of
the commit seven fd 2173 begin get rebase episode naturally the way that that things I guess
should happen is that that's the the basis for this for this for this branch so when I merge back
into into a master I am going to come in at begin get rebase episode seven fd 2173 and I'm going
to put my changes in line from that point and that's why you have for instance glue and rogue
and then dragon and then paladin and then the merge branch but but you see how how this doesn't
it reflect accurately the order in which these objects were created so ghoul and then I switch back
to master and did rogue and then I switch back to experiment and did dragon then I switch back
to master and did paladin and then I merge so you it's an accurate history of how this of what
literally happened on this branch emerge is a get merge is a very precise and correct and realistic
almost almost too realistic in some people's view depiction of of the life of this branch of master
and and everything around it so a rebase is telling a lie it is lying to everyone and it's saying
it is almost representing it as if though as if though history has been what was different
so according to rebase we had begin get episode get rebase episode and then we got two new files
called ghoul and dragon and then we got two more new files called rogue and paladin and it just
kind of magically happened in that order even though that's not what happened we it's it actually
did we actually did ghoul rogue dragon paladin in this version we got sorted we got ghoul and dragon
from the experiment branch and then we got rogue and paladin from the master branch and no merge
message at all it's just it all sort of natively happened on master it's almost as if though
everyone was completely coordinated and and merging straight to master at all times so there's
really no sense of branching or forking or or or conflicts or anything like that it just all
sort of gets tidied up and made very pretty and orderly and that's that's really that's what a
rebase is that's all a rebase is it is it is a deceptive tool within get to make your to to make
some branch look better than it actually is and that's really all there is to it I mean that's
rebase in a nutshell I mean there are other options to rebase there are there are methods whereby you
can make commits and squash the commits into into what appear to be just one big commit it's it's
dash dash auto squash I think for rebase and dash dash squash for emerge the controversy you'll
hear about rebasing is is as I've said it does rewrite history it it it lies it's it it is not
an accurate reflection of how the project has developed which in some cases you could imagine
being problematic maybe if there's some kind of regression that that someone did maybe seeing
that process out of order if you're going back and sort of looking at the history of the projects
or of the the files in the project maybe maybe a rebase lying to you telling you happen different
would be confusing I'm not I'm not convinced of that I have worked on some some fairly complex
projects on the periphery I mean I'm not I wasn't the one driving it but I mean I've I've
worked on projects where they do they did a regular rebase every time that they pulled contributor
code into a project they did a rebase so that your code got pulled in kind of as a as a branch
and it got replayed over over the new the new branch point and it kind of it had the effect of
keeping everyone's contributions sort of bundled it together in a logical way it got rid of all
the merged commit messages and it just kind of it really worked really well I I really enjoyed
working with that project because because that master branch was so sort of um
as it was it was organized in a logical way rather than
it just so happens that today so and so did a lot of work on that branch and took a break from
it in the afternoon which is the exact same time that someone else decided to do completely
different work and yeah it's great to have that sort of honest reflection of this is exactly how
this branch came to be but honestly it it what for who cares it's much better to have all the
branches at least I found it was much better to have all the branches kind of come to fruition
they sort of met their purpose here's a branch I'm going to implement this feature and it is
going to happen in this branch and when I'm finished implementing this feature we'll take
that branch and graft it back into the master branch and it will all be sort of task oriented
rather than a snapshot of how reality actually are betrayarily ended up happening other people
of course say that that's ridiculous and and you shouldn't do that because it's not correct and
you should merge branches and that is exactly how they should occur and when that's just the state
of the project and if you can't follow the trail through the code maybe you've got other problems
with how you organize your project I don't know if either of those two views are completely correct
I don't know the greater philosophy of code management and that sort of thing there are probably
lots of arguments to be had and you will hear them over people who really like to be pedantic about
about code management and about get itself and and so on all I know is that the experiences that
I've had with rebasing has been has all been very positive they've they've resulted in what I
consider a cleaner code base or a I should say a cleaner I guess what I'm saying is a cleaner get
log and and whether that's a good thing or a bad thing and whether I'm leaning on a crutch of
of of deception I don't know but that is what rebasing is it's there if you need it it is there
if it helps and it's not as maybe as confusing as as one might think it really isn't it is it is
simply moving the the base or the foundation of where your branch got branched off from
oh around along the the origin point from that master branch it's all it is it's pretty simple
so that's everything you need to know about get rebasing I guess use it well use it wisely use it
proudly talk to you next time
you've been listening to Hacker Public Radio at Hacker Public Radio dot org we are a community
podcast network that releases shows every weekday Monday through Friday today's show like all our
shows was contributed by an HBR listener like yourself if you ever thought of recording a podcast
and click on our contributing to find out how easy it really is Hacker Public Radio was found
by the digital dog pound and the infonomican computer club and it's part of the binary revolution
at binrev.com if you have comments on today's show please email the host directly leave a comment
on the website or record a follow up episode yourself unless otherwise status today's show is
released on the creative comments attribution share like three dot org license