git rebase - Why, When & How to fix conflicts

Why, when and how to do git rebase. How to fix merge conflicts during git rebase.

If you like my style of teaching, I'd love to see you at a workshop!

Fixing merge conflicts:

Video on `git pull --rebase`:

How to change your default editor in git:

Use the following command to change your default editor to VSCode:

If you use a different editor, just Google "git set text editor to $yourEditor", it's usually easy to find.

Git Graph Extension for VSCode:

If you don't use VSCode, you can also use SourceTree, which is free.

0:00 - Why rebase?
1:54 - Squash vs Rebase
2:11 - How to rebase
3:22 - Downsides of rebasing
4:37 - Fixing conflicts
5:28 - Conflict resolution example
8:15 - Interactive rebase

Thank you to Jonas Geiler and Bruno Paulino for giving great feedback on drafts of this video!

LEGAL DISCLAIMER
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
Everything here is for informational purposes only. All non-licensed clips used for fair use commentary, criticism, and educational purposes. See Hosseinzadeh v. Klein, 276 F.Supp.3d 34 (S.D.N.Y. 2017); Equals Three, LLC v. Jukin Media, Inc., 139 F. Supp. 3d 1094 (C.D. Cal. 2015).

[rascta]

I'll add a tip that you lightly touched on: never rebase on another branch without *first* squashing your branch on itself. That way lies madness.

Picture this - you've got 20 commits and you're rebasing on main (or whatever) that has several commits. If you get a conflict, that's *not* a conflict between the current state of your branch and the current state of the other. It's a conflict between the state of your branch 20 commits ago, 19 commits ago (plus changes from last conflict resolution), 18 commits ago (plus changes from previous conflict resolutions), etc. So you have to mentally time-travel back in time to fix what the conflicts would've been at each point in time, for each and every commit, including between code that you didn't write back then but modified during previous conflict resolutions. Possibly introducing more conflicts and/or bugs all along the way. In the end, you haven't rebased the current state of your branch on the current state of the other, you've added all kinds of changes along the way. Now you have tons of changes and untested code that you're pushing.

In a merge commit, *or* if you've squashed your branch into a single commit and *then* rebase, in that case you're only dealing with conflicts between the current state of the two branches. Which is *vastly* easier to wrap your head around and understand and test. No time-traveling needed, no accumulating bugs.

That of course means that you lose your commit history of how you got here from there, since you only have 1 commit instead of 20. But at least you have your sanity.

[bobDotJS]

I have been doing this for years professionally and just learned about cherry picking.

Thats why your channel is important. Git education sucks.

[ARKGAMING]

The first two minutes I was like "our team squashes the commits so the merge commits don't matter"

But of course you pointed it out as an option

[lloyd]

I need more content like this, it's very useful and it keeps me focused while programming

[vladislav_artyukhov]

Beautiful explanation. I haven't found some good guides earliers, and now found perfect

[adrians]

You explain it so easy

I hope you keep with this type of git videos 😅

[streettrialsandstuff]

I'm using rebase for many years now. It's the best way to deal with history and conflicts.

[alperari]

Funny that your video was uploaded yesterday and i just today had to do a rebase for my company's project and referred to your video. Thanks!

[thedelanyo]

This channel is a gold mine. Please keep it up. 😅😅

[saurabhsoni]

This video needs to reach masses !
Exceptional explanation - to the point and succinct animations !!
There are abundant videos on this topic but this one really stands out - Wow!

Thank You for putting in so much effort to make this - I have consumed this and I am grateful.

[mindmaster]

Very good explanations. I confess I´ve worked with git for many years without fully understanding the rebase concept. Thanks a lot

[mln]

I always do rebase, even when I have pushed multiple commits. When that happens, I just do git push -f origin <branch>.

I've never had any issues with this method, and I've been rebasing like this for years. If you think about it, once you rebase, what's on the remote doesn't really matter anymore. What matters is the new rebased branch, so a git push -f is perfectly fine.

[stanislavkozak]

Wow! Such a clear explanation. I should have watched it before I started fighting the Lord of Branches myself. 😅

[nandordudas]

"never push if" - you can do anything on your branch (rebasing + force pushing, etc.) until any other users not connected or touching your branch

[volodymyr.brodskyi]

I like your videos! Really informative!

[wadecurry]

You tell beginners to switch away from vim!?!? The learning curve is GOOD for ya!! It made me what I am today!

[CottidaeSEA]

Really good video, it tells exactly why I am hesitant to ever recommend rebasing. I'm glad you mentioned you were working on it in the replies.

[sahil_singhai]

Dude, Respect. Love this video and even my manager 6+ year exp don't know how does rebase work. but I know now. please use more examples like the one you did here, that helps alot to understand better. giving you a subscribe buddy.

[residual-entropy]

Nice video! Would love on one squash-and-merge and how it compares to rebasing. I’ve used both a decent amount but don’t feel like I totally understand the pros/cons/differences. :)

[xtkozvn]

great video as always.

previously i thought, when i have a rebase conflict i should do `git add`, `git commit` .
i didn't know about `git rebase --continue`. 🤦‍♂

thank you very much!