All right, so we finally get to try the rebase command.
I'm going to do exactly what I'm showing you in this diagram.
Currently, I have my FT branch feature, whatever that feature is, where I have twice merged in changes
from master.
So my master branch still doesn't have any of the feature stuff.
That's fine.
I don't want to directly merge anything into master right now.
Instead, I'm just concerned about getting the changes from my coworkers that are constantly adding
to master, even if it's not constant.
Let's just say frequently in a given week, updating master pole requests are merged in I need that
work on my feature branch, so I merge from master into feature, but that gives me merge commits.
So instead I'm going to rebase.
And again when we use the git rebase command, we are rewriting history.
So this is the actual history of our commits.
But when I rebase, things get switched around a bit.
In fact, we get new commits generated.
So instead of creating merge commits for us when we use git rebase, it rewrites history.
It creates brand new commits for each of the original feature branch commits.
So the workflow here looks like this.
I want to be on my feature branch and then I call or I run git rebase master.
So this is not going to screw up or change the master branch.
Instead, it's going to rewrite history by taking my feature branch commits, creating new ones that
are based on the originals and putting them all at the tip of the master branch or starting them at
the tip of the master branch.
Re Basing them at the tip of this master.
So all that work, however many commits I have on my feature branch, that work is not going to be destroyed
or anything like that, but the commits are going to be recreated and they're going to be added to the
tip of my master branch.
So we end up with a linear structure.
We still have two branches, of course, because a branch is just a pointer with just a reference.
But now we don't have these merge commits where if we don't really need to go into it now, but each
one of these merge commits has two parents here.
Every commit has a single parent.
Except I guess the first commit on the master branch.
So let me demonstrate this.
As we saw, we already have merge commits so we can rebase now.
I'm showing you sort of merging first and then rebasing, but you can actually rebase instead of merging.
I'll show that.
So here's our structure right now.
I'll zoom in as much as I can in post-production.
So we have Master Branch here on the right feature here and we have these merge commits.
So instead of this structure, I'm going to rebase.
And I guess what I'll start with is I'll show you these commit hashes.
Maybe I'll take a screenshot of them.
Now I'm going to run this command.
So I'm on the feature branch.
Let's say I make sure I get the latest changes on the master branch.
I pull down from GitHub on master.
I've got the latest that whatever coworkers have merged their code in.
Now I'm going to call get rebase.
I can type it, master.
And I'm calling this from my feature branch.
Okay.
So take a look at this output rewinding head to replay your work on top of it so on top of master and
then it applies my commits, my three commits.
So let's see what that looks like.
So I'll zoom in here.
Hopefully I do follow through and zoom in in post-production.
And our structure has changed pretty radically.
So all of my work is still here.
We still have those three commits I made on feature.
We just don't have those two merge commits.
So now things are linear.
We still have two branches of course, but we've created new commits or git has created new commits
for us based upon the original commits on the feature branch.
So if I type get logged now first I'll just show you.
Still two branches master is unchanged, but now if I type get log I'll do one line.
We have fewer commits because we don't have those merge commits and the commit hashes have changed because
we actually end up with new commits.
So the original commits on the master branch are unchanged to be to be three for f, three for f.
Right.
What else is on master add footer e19e19.
Anyway, the three commits that I made on the feature branch, however, like begin feature if we take
a look at it on the original screenshot, I took eight, eight, nine.
Very different.
It's a completely new commit 907 So I rewrote history, I made new commits, the work is still there.
I still have those commits, the commit messages and actually the dates are still in there, the metadata,
but they are in fact new commits.
It's not just like an update to a committed, it's new history.
So what this does, though, is hopefully you can see it cleans up my history for this feature branch
significantly and it makes it easier to see what I've done, like the actual work on this branch because
it's all here now.
It's not mixed in with that work from master, even though the code is all there together, but the
commits are all together.
They're condensed down.
So I can see, Oh, this is what I've done, right?
Those are the commits I've made on this branch versus originally.
Let me pull that screenshot up again.
If we look here, we've got this from the master branch and then this in the Master Branch Feature Branch
Feature Master.
This is on feature, it's a merge commit feature master feature versus here it's just master master,
master, master those four and then feature feature feature.
Master, branch, master branch, master branch, master branch and then feature, feature, feature.
So that is our first example of using Rebase.
We've done exactly what these diagrams showed, but I also want to show that we can just use rebase
instead of merging.
For example, if we quickly make another change on the master branch.
So we're on the master branch.
What else is added login form?
How about image gallery added?
I don't know really.
This is probably not how you would break up development, but anyway, let's just do something obvious
like that.
Image Gallery added.
So I'm going to do a commit on the master branch add image gallery.
So that's something a coworker does.
I switch back to feature.
I don't have that right.
So now we've diverged again.
We don't have this linear structure and if I want that work that I just got pulled down from GitHub,
let's say that a coworker did.
I want that on my feature branch that I'm currently developing.
I want to stay up to date instead of merging.
I'm now going to rebase and the end result will be what I just showed you in the previous example,
where we've rebase the feature branch on top of master.
So instead of merging and having a merge commit here on the feature branch are three feature branch
commits are just moved on top of that last master branch commit.
So we rebase it on the tip of the master branch.
Okay.
So I don't have this commit on my feature branch about what was it again.
Image Gallery.
I don't have that on feature branch, but I'm going to switch to it.
I'm currently on it.
So make sure if that we're on feature.
Oh and if I want just to check in, what's the difference.
I can do get diff feet master and quickly see I'm don't have this image gallery added I mean we know
that but if there was more work I would see there's a bigger diff between feature and master or vice
versa.
So I'm going to rebase get rebase master.
I'm on the feature branch.
Okay.
So this is the current structure, what we see.
And get re master here we go rewinds head to replay our work and this is what we end up with.
So even though there was just one new commit on master, right?
This ad image gallery commit all of my commits on feature were recreated.
There are new commits and I didn't take a screenshot of the commit hashes, but these are different
from what they were just a moment ago because these are new commits based on the original commits.
And so now we're back to this linear structure, right?
So I can do this instead of merging.
I don't need to merge.
I can only rebase or I guess as I showed you originally, you can merge, merge, merge.
And then at the end say, okay, I'm going to rebase now before I share this with people, I don't want
them to see all my merge commits.
It's really depends on the workflow and we'll talk more about the pros and cons and especially about
the golden rule of rebasing, which is when not to rebase.
So hopefully this is becoming a little bit clearer when we rebase a branch, we are basing that branch
on the tip of another branch.
So if we switch to whatever branch our feature branch, we rebase on to master.
That's the part that sometimes a see students get confused about.
They think get rebase master means you're actually rebasing the master branch, but in fact we are rebasing
on to master in this case.
So our feature branch commits are recreated, new history is made and it all begins at the tip of the
master branch and we end up with this nice linear structure.