Abort

[00:00:00]
>> Nina Zakharenko: Remember there's a safety option. If you're doing a rebase, and before it's done, if things are really going wrong you can always use git rebase --abort. Pulls the ripcord, cancels it, and you're good to go. Here is a pro tip that for some reason I don't see a lot of people using, but it's a great idea.

[00:00:21]
If you're gonna rebase, fixup, squash, reorder, if you're gonna be messing with your commit history, just make a copy of your current branch before you do it. Git branch makes a new branch without switching to it. Now, you can rebase to do whatever you want. If you mess up, you can always reset back to that backup branch, otherwise, just delete it.

[00:00:43]
Rebase doesn't have to be scary, this is a really great way of playing around with it without making your changes final or permanent. So rebase, incredibly, incredibly powerful, you can slice and dice your git history however you want to. It's easy to fix previous mistakes in code, you can keep your git history neat and clean.

[00:01:06]
>> Nina Zakharenko: This is particularly important with a mantra of committing early and often. So you should try to commit as much as possible while you're doing your work because at any point you might lose changes, you might forget something. You might have to walk away, you come back, and you're like, where was I, what was I doing?

[00:01:25]
Commit early and often, and locally rebase to your heart's content. Once you're ready to share your changes with your co workers, they don't need to know you made five commits in an hour. You can just present them with the pretty neat, clean history, and that's it.
>> Nina Zakharenko: So make sure you follow this mantra and one thing you shouldn't do.

[00:01:53]
I've seen a lot of developers do this is they use rebase to squash all their commits into one commit, don't do that. That's really awful, makes it hard to debug when a bug was introduced. It makes it hard to code review, so avoid that temptation of I'm done with a feature, let me squash these into one commit.

[00:02:11]
And again, a warning, never, ever rewrite public history. Rebase commits are copies, if other people are working in that same repository, they'd be working on different commits. And you can cause some damage, massive merge conflicts, you can cause people to really lose their work.
>> Nina Zakharenko: So if you rewrite public history, monsters will eat you.

[00:02:34]
Not really, but developers will be angry with you. So now that you can see that rebasing can get messy, but if you understand the basic concepts of how git works under the hood, it makes the concept of rebasing a lot simpler.