In this video, we'll quickly talk about why you might want to rebase.
We've kind of already touched on it, but also most importantly, when you should not rebase what the
golden rule is of rebasing.
So why rebase instead of merge?
Imagine this repo is way more cluttered.
Well, not cluttered, but there's a lot more history.
Hundreds of commits and a lot of simultaneous work going on.
We can see with the way of structure this very clearly what work I did on the feature branch.
It's these three commits right here because we rebased.
So it doesn't matter if a whole bunch of let's say there's ten or 50 or 100 other commits from the master
branch and they happen simultaneously over the course of development that I was working on feature.
Assuming that I get those changes, I pull them down to master and I rebase onto the master branch.
My feature branch commits are all located together at the tip.
This makes it easier to for someone to review my commits and take a look at the code base and try and
read what's going on and open source projects with thousands of contributors and tons and tons of work
all the time.
This makes it easier for some random person to go read the history.
Go try and understand what to this feature do.
Right.
I don't have to see like a million merge commits as part of the commit history.
The end result is the same.
I guess I didn't really actually show you the code here, but we still end up with the code coming from
the master branch mixed in with a feature branch.
So we have Image Gallery added.
It's just the actual history that is updated.
So because we are updating the history because rebase rewrites, commits, there is a big no, no,
a big thing you should be aware of.
You do not ever want to rebase commits that other people already have.
So you don't want to rebase if you've pushed up some branch to GitHub or somewhere else.
And your collaborators have that work on their machine because then they have those commits and then
all of a sudden you rebase and you rewrite those commits, you rewrite history.
That is a nightmare.
It's not a nightmare, but it can be really, really annoying to reconcile.
When your collaborators have different histories, you have commits that just don't even exist in their
history, and they have commits that don't exist in yours.
And it's all in the past.
That can be very tricky.
So again, the rule never rebase commits that you've shared with others.
So what this means is you want to be rebasing commits that you have on your machine and other people
don't.
So your feature branches that you're working on, you don't want to rebase the master branch because
people presumably have that master branch or the main branch they have commits that you have.
So if you rewrite those commits and they're totally new, that's a problem when you try and push up.
So you don't want to do that.
At least that's a general principle.
So you work on a feature branch, whatever you're doing in there, fixing a bug, adding a new feature,
whatever it is, you can rebase your work from that branch onto the master branch or onto another branch.
Right.
You're not changing the master branch.
You don't change the branch that you are rebasing onto.
Right.
We didn't change the master branch here.
We only changed my commits on the feature branch.
So that's important.
The branch that you are on when you call rebase is the one that is rebased, as we talked about.
Let's go back here.
Here.
I'm on the feature branch I rebase onto master.
That's fine.
I'm not messing up, master.
I'm not changing the history on Master.
I'm only changing the history on my feature branch.
I'm changing those commits.
So that's okay.
You just want to avoid rebasing, commits, rewriting history that other people have.
So once you've pushed that feature branch up, if somebody has pulled that down, if they have that
history, if they're working on it, if you don't want to, you don't want to rebase, at least that's
a general rule I recommend.
Again, there are ways of fixing this, but it's not it's not fun.
All right.
So that is kind of why a lot of people shy away from rebase or why I was told not to use it, because
you can get yourself in situations that are that are hairy.
If you're collaborating with people, you're rewriting history.
And if you don't know how to how to properly use rebase, that can be a big problem.
So make sure you know what you're doing.
And if you're working at a company like, they're going to make it very clear to you what the workflow
is.
And if they expect you to rebase everything or to never rebase and only merge or rebase in X situations,
it's just part of learning the git workflow at a particular company.
But on your own, if you're working on your own projects, just you, then you can rebase all the time,
of course.
But also, even if you're just on a small team rebase all the time, just make sure you know what your
rebasing and don't rebase shared history any commits.
People already have only rebase stuff that is yours and yours alone.
Rebase it and then you can push it up.
Right?
You get this nice, clean history, you don't have all those merge commits, do that and then you can
share that.
So I'll show another example of this next with some conflicts if you want to see how that works.
It's the same principle roughly as resolving merge conflicts when you're merging, but I'll demo it
anyway.