So as I mentioned, there are two main things that we can do with the get rebase command.
We're going to focus on the first of those things, using it as an alternative to the git merge command.
So both commands get merged, get rebates, help us combine changes from two branches.
So I'm going to start by identifying the I guess you could call it the problem with merging or something
that rebasing addresses that merging does not.
So imagine that I'm working on a project with, let's say, ten different developers.
I'm at work and we're working on some big code base together, ten of us.
Okay, so we have our master branch and there's like a million commits before it that you can't see.
Well, maybe a couple thousand commits then it's my turn.
We have stand up.
It's my turn to work on our new feature this morning.
Well, everyone works in a new feature, but it's time for me to start a new feature.
So I make a new feature branch.
We'll just call it feature and I do some work on that feature branch.
Right, so there's a new commit or two or maybe more continue doing more work.
We end up with more commits on my branch, but in the meantime, maybe a couple of hours pass, maybe
it's lunch and one of my other coworkers finish their their task, their bug fix or their new feature
or whatever, and that code is merged into master.
Now probably they make a pull request or there's some mechanism in between, but the end result is that
their changes are merged into master.
So I probably want that new work on my feature branch.
Right.
Maybe there's a bug fix in there or something.
I don't want to diverge from the master branch for a super long time without getting those new changes.
So how do I get that new commit?
Hopefully this is nothing new.
How do I get that new work from the master branch onto my feature branch?
Well, I merge, right.
So this cannot be performed as a fast forward merge.
We end up with a merge commit.
That's what I'm highlighting that purple background with a green or whatever cyan color that's supposed
to indicate a merge commit.
So there's a merge commit on my branch and then I keep doing some more work.
Right.
And then what do you know as I'm doing more work the next day on my feature branch, there's more new
work added to the master branch.
Another coworker pushes up some changes.
Maybe it's even more than one.
Maybe it happened five or six times in a day, depending on what they're fixing or working on.
So I need to get those commits onto my feature branch or I need to know about them.
So I do the same thing.
I merge and yet again I have a new merge commit, right?
So as I continue to work, imagine that instead of what five commits here or something, I have a whole
bunch of commits on my branch, my feature branch.
Maybe I'm working on it over the course of weeks, not just days, and the rest of the team is very
active.
So we have a very active master branch, lots of changes happening in the meantime.
So I need to continuously merge those in and I end up with all these merge commits.
So my entire feature branch might have dozens of merge commits that don't actually say anything about
what I'm working on.
They have nothing to do with my actual code or with my commits.
They just have to be there because I merged, right?
We don't have a way around that.
So again, try and visualize this on a much larger scale.
So instead of just the small number of commits, I can fit on this one slide and a tiny diagram.
Imagine that I'm merging pretty frequently just to get those changes from master whatever my coworkers
are doing, and if it's a very, very active project, that could be a lot of merging onto each feature
branch.
And my coworkers all have to do that too, right?
I'm not the only one.
They're all working on features and if everyone else has merged changes into Master, they need to get
those changes onto their feature branches.
So everyone's feature branches might be riddled with a bunch of merge commits and then when they merge
those back into master, there's just a bunch of useless merge commits as part of the history.
I shouldn't say useless, but they're not informative.
The commits might be something like fix ex bug, add new feature, remove x file and then merge commit
merge blob branch.
Right.
That's just sprinkled in there and that makes our history more annoying, muddier, less clean.
So that is something that rebasing can help us with.
So I'm going to show an example repo.
We'll set it up in the next video, but I'll just show you on slides for now if we rebase instead.
So rebasing is just another way of combining branches instead of merging.
What happens when we rebase is that we actually rewrite history and this is why it's sometimes problematic.
We are rewriting history, we're creating new commits, or we have git create new commits for us based
upon the original feature branch commits.
So here's a diagram, the same diagram from before up top.
Here's my feature branch.
This is what happens when I merge in all those changes right from the master branch and I get multiple.
Merge commits, but if I use rebase so I'm going to rebase the feature branch onto the master branch.
Think of the term rebase as re.
Well that was I was going to say rebase.
That's exactly what it is.
We are coming up with a new base for our feature branch.
So what we end up with is this linear structure.
We will go into detail again on how this all works and I'll demo it.
But notice a linear structure.
We have the master branch and then we have our feature commits from that feature branch on top of the
master branch added to the tip of that master branch.
So we don't have these merge commits, right?
We have the same original like the three commits I did on the feature branch, the four commits from
the master branch, but they've actually been rewritten.
So this doesn't indicate the time where things were made, where commits were created.
Each commit actually has a date, so that is preserved, but commits are moved around in order to give
us this new structure.
So all that feature branch work I have done, all those commits begin at the tip of the master branch.
So I don't have these merge commits anymore, but the end result is that whatever I'm working on here
contains all of the commits from master and from feature, just like it does right here.
It's just a different mechanism.
And here's a similar example where instead of having these merge commits, I just wait.
So I have my feature branch and then I want to get the changes from Master.
Combine them with feature.
Those new commits I can rebase in order to end up with this structure.
My feature branch has a new base at the tip of the master branch.
So it begins where master ends and we end up with this nice structure, linear, it's cleaner and it's
more focused.
Write the history here.
Someone can see very quickly.
These are the commits that had to do with my branch and the changes I made versus here.
Those commits are still there, but there's these merge commits that are in the way.
So if we multiply that by ten people working on feature branches merging all the time, that's a lot
of merge commits, but if they all rebase in the correct way, it's a lot easier to see what's going
on with their individual branch history.
All right.
So I'm going to demo this in the next couple of videos.