Rebase

[00:00:00]
>> Nina Zakharenko: What is rebase anyway? So let's imagine that our tech posts branch and our master branch have diverged. And we don't wanna have a messy merge commit in our history. But what we can do is we can pull the latest changes from master. And instead of having our commits be mixed in somewhere sandwiched between commits from master, what we wanna do is we want to apply all of our commits cleanly on top of the master branch.

[00:00:28]
And we can do that by changing the parent commit of our commits. So what rebase means is give a commit a new parent, i.e., a new base commit. So the first thing that rebase does is it rewinds HEAD. So in this case, I've checked out tech_posts. If I want to rebase for master, master has one new commit since I've made my branch.

[00:00:59]
>> Nina Zakharenko: First Git is going to rewind HEAD back to master. It's going to end up replaying my commits on top of HEAD. So now giving commit 4080. That was our original commit on our branch, it's now gone. And we've created a new commit, a copy of that commit on the tech_posts branch.

[00:01:31]
And now that tech_posts branch is up to date with the latest commit from master. This makes resolving merge conflicts much easier, you can rebase pretty frequently.
>> Nina Zakharenko: And not so scary at all. It makes history a lot neater and cleaner, too.
>> Speaker 2: So I missed about the merge conflict.

[00:01:56]
So if 2b25b38 has changes in the same files as 4080a?
>> Nina Zakharenko: Then, you'll have a conflict. Then, you'll have to fix it. But if there's no conflicts, it'll just cleanly apply.
>> Nina Zakharenko: So merge versus rebase. If we're on the tech_posts branch, if we rebased from master, our copy, the commit that was our commit in the tech_posts branch will now be a new commit pointing to the latest master.

[00:02:36]
Or if we merged from master, we would actually have a merge commit. So a brand new commit would be cluttering up history. But if you're contributing to open source, that's not really ideal. Mostly, we wanna keep our history neat and clean. And it prevents a bunch of merge commits from cluttering it up.

[00:03:01]
>> Speaker 2: So it's a little bit like a fast forward?
>> Nina Zakharenko: Yeah, a little bit. It's kind of pretending as if we could fast forward by changing our parent.
>> Nina Zakharenko: The power of rebase really comes from interactive rebasing, and that’s replaying commits. When those commits are replayed, we can edit them, we can remove them, we can combine them, reorder them, insert them before they're replayed back on top of HEAD.

[00:03:33]
So we can fix them, change them, edit the messages, do whatever we want. Interactive rebase is done with a -i flag. It's gonna open in an editor with a list of to dos in the format of commands, then commit, then commit msg. Git is going to pick those commits in the order that you specified.

[00:03:54]
Or it might stop to take an action when something like an editing or a conflict occurs. You interactive rebase with a shortcut, git rebase-i, the commit that you wanna start fixing from. But then you should specify its parent.
>> Nina Zakharenko: All right, when this list of to-dos opens, make sure you don't change any of the messages in the list.

[00:04:16]
Git only ignores them. Git ignores them. It only looks at the [INAUDIBLE] that are present. So some of our rebase options, and this will come up when you do an interactive rebase in your editor, but in plain text, pick will keep this commit. Reword will keep the commit, it's just going to change the message.

[00:04:36]
Edit will keep the commit but stop to edit more than the message. And squash is going to combine this commit with the previous one. It'll also stop to edit the message. Fixup combine the commit with the previous one, but keep the previous commit message. And exec, which is really cool, it lets you run a command on this line after picking a previous commit.

[00:05:02]
So if you're rebasing and you wanna run a test in the middle, you can do that with exec. Lastly, drop will remove the commit. But the same thing will happen if you just remove that line, the commit will just be killed. So here's an example rebase. I'm doing a git rebase -i from this commit in the parent.

[00:05:23]
I'm saying reword where I add the posts/django-framework, and squash the commit where I said, oops, I forgot to add an index entry. When I git log oneline, I have now added a blog post explaining the pros and cons of Django. That's the new commit message that I've done with the rebase.

[00:05:48]
And now those two commits are smushed into one.
>> Nina Zakharenko: And when I do this, my editor will open. It's gonna open twice, once to reword, that is change the commit message, and then again to squash, combine commits. We can also use rebase to split commits. That is when we edit a commit, we can also split it up into multiple commits.

[00:06:11]
Let's say your commit was too big, had to much information in it. You wanna make sure that your commit is only representing kind of one logical group of changes. You can split it up with rebase. I'm going to skip explaining this. But if you have a copy of the slides and you wanna go back to this after class, it's on slide 150.