Rebase

[00:00:00]
>> All right, so now we're gonna go from merge to rebase. I know everyone's excited about rebase. The thing about rebase is I am completely convinced people don't like rebase because A, they heard on Twitter that it's bad. B, they used rebase that one time, screwed it all up, and now they hate it.

[00:00:20]
And it's ruined their life, therefore rebase bad. It's not bad. It's actually fantastic. Rebase is just yet another tool in your get bad belt to be able to manipulate and use your repo effectively. There's actually a really good reason why you should use rebase. We'll kinda get into it a little bit more.

[00:00:37]
So this is our current setup right now. We have fool. Which is BC, and we have trunk, which is all the way up to Y at this point because we have merged on bar. So this should be your setup right now. Now we can demonstrate the power of rebase by updating where foo points to.

[00:00:54]
We're gonna create this graph by using rebase. This is what Rebase does is it allows you to update underneath your set of changes. This is very important because it is rewriting history in some sense, but it's allowing you to have what is currently the reality, then your changes as opposed to your changes that are taking.

[00:01:20]
Tested against some previous reality that's no longer true, you can now have it properly in line and then to be able to find out did you actually write something that's good or does it suck? This also means when we decide to merge foo onto trunk, we can do a fast forward merge.

[00:01:40]
Cuz again, our best common ancestor our merge base is the tip of trunk, now that we rebased. And this is typically why people really like rebase is that allows no merge commits. And there's a good reason why you don't want merge commits and we'll cover a little bit later.

[00:01:57]
Alright, so basic steps of what rebase does. First thing rebase does Is that you will first go get rebase target branch. Second, what it's gonna do is it's gonna actually check out the latest commit on the target branch. So you're no longer on your branch. You actually switch branches to the target branch.

[00:02:15]
Then it's gonna take the branch that you were on, the current branch, and play the commits one at a time Time in order onto the target branch. Then it will go back check out your current branch and update current branch to point to that latest commit. So therefore it actually just moves your commit forward in time and plays it one at a time.

[00:02:39]
So that's So that's how you got to think about merge. It's a little bit, or a rebase. It's just a little bit different, but it's very important to understand that cuz down the line, rebase is going to cause a lot of problems if you don't know about that specific feature.

[00:02:55]
All right, I want you to rebase foo with trunk. Create a separate branch, It's called foo rebase trunk. And so you're going to do a, you're going to literally do a git rebase trunk on this branch. So I'll do it myself too. I'll check out foo. And you can do a git log if you're curious, right?

[00:03:17]
There you go. A, B, C. And so then I can do one on trunk. A, B, or A, D, E, X, Y. And then I can go git rebase. Git checkout. Almost messed that one up. There we go. We'll create the new branch, foo rebase trunk. And I'm going to go git rebase trunk.

[00:03:39]
All right, we've rebased. So what happened? Well, let's look at the log, get, log one line. Look at what we see. We see trunk, but we also see. Our two commits that differed from trunk. Now after Y, we now have history that is linear. So now you see that trunk, which.

[00:03:59]
Contained bar, as our last merge is now the base for foo-rebase-trunk. In other words, food is no longer diverging from trunk. It's now literally walking the history forward, which means we can fast forward merge if we want to. So there are some pros. Obviously, you get a clean history with no merge commits.

[00:04:18]
So if you use get logged To kinda look through things if you wanna walk backwards through changes, there's just significantly less kind of commits to have to go through. The cons obviously, are that it alters branch history. And when you alter branch history, if you have the same branch on another repo, you then have a problem because you have two branches, named the same thing with two different histories.

[00:04:39]
So this is. Typically where you see that git push force cuz you want to forcefully tell the other repo, I know what foo has, and my version of foo is more correct than yours, so you need to update everything. All right, some cautionary words, never change the history of a public branch.

[00:04:55]
I believe Mark over there, Mr. CEO, actually has done that once before For and it's a major pain it's a super pain don't ever do that. So typically, what you'll see is always merge on public branches rebase on private branches so you have some change, you wanna make sure they actually work with the latest part of whatever you're working on, you can then rebase it forward, run your tests, run whatever, everything works if you have a conflict Grantham resolve it then That way you have your private branch being altered in history, but your public branch never changes history.

[00:05:25]
The moment you do that, it breaks everybody. Everybody breaks the moment you change public history. So don't ever do that for any reason. There's a lot more, but we need some more foundational knowledge before we go over it. So we kinda have a nice little base here. Now, you no branches Merging, rebase, you kind of get how they work.

[00:05:42]
You understand how commits work. You actually understand that it is the storage point of the entire repo per commit, but it's efficiently stored, so it's not a waste of space. This is also why whenever you're downloading a Git repo that has a long history, it takes a while because it's literally downloading every single Change possible cuz it needs to be able to reconstruct the repo at any one time.

[00:06:03]
That's also why if you do a git clone and use like depth one, I believe is the proper option. It will actually just come down with only the last commit, which will contain the entire repo. That's how you get that efficient checkout.