Should you squash pull requests on GitHub?

Squashing pull requests on GitHub has advantages and disadvantages. I generally prefer rebasing locally.

Get my interactive git cheatsheet as soon as it's released here:

My best video yet (interactive rebase)

My first video on git rebase (without --interactive)

My Top 10 git shortcuts:

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.

0:00 - Squash
0:35 - Downsides of merging
1:37 - Rebase
2:00 - Comparison

Thank you to angymares for giving excellent ideas and advice during the video creation!

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).e

[thoat]

I have watched a couple of your git videos, and thanks for bringing up these nuances in keeping a sane and meaningful git history :D I often take the same approach as you do, rebasing locally, squashing some commits while keep others for debugging. Not many developers I know are aware of these practices. Now I have your video to show my colleagues when needed!

[brnto]

This is why GitLab has semi-linear history. A branch is first rebased to the head of the target branch, then a merge commit is made from the branch into the target branch. It looks quite nice because it’s linear, you can clearly see when different branches get merged in, and you can still see the individual commits from when the branch existed. It’s an extremely nice workflow.

[computerhoofd]

Dude, your animations are incredibly good. It really enhances your explanations.

[rikschaaf]

I usually like rebasing onto main before creating the PR and merging (no-ff) after the PR is reviewed. That way it's easy to tell apart features that were implemented, while still having a clean graph.

[MrCdburgerjr]

This is a great balanced explanation showing the advantages and disadvantages of each method. I really like your work. I opened the video wondering, "Is he going to mention X, Y, or Z?" And you mentioned almost everything I was looking for. 👍
When you mentioned that the squash merge makes a straight linear history, that was a good opportunity to mention that you can get the same effect using normal merges with the "first-parent" view, but still have the smaller individual commits linked in the history.
My team uses the --fixup feature so that we can just keep adding commits to the topic without a disruptive rebase. A --fixup commit lets us fix a private bug in a previous commit or finish a WIP commit. This makes it easy at the end of the topic to --autosquash before the PR and have a clean topic before publishing.

[ReluctantSpirit]

Excellent explanation as software engineer there are gaps in my knowledge which were never filled but thanks to you they’re complete now

[bernhardkrickl]

Great summary! Since it is highly recommendable that you produce small commits and small PRs, it follows that you should always be in a state where the squash strategy is the best. :)

[soverain]

Excellent video, as usual! Keep up the good work, cheers!

[landsman]

This is really good. I work the same way for years. Recommended.

[tobiasfedder]

Great video!

I prefer the interactive rebase on feature branches, including fixup, squashing, and even creating new commits where it makes sense. Also the occasional force push; unless there is a PR/MR with an assigned reviewer, that'd be rude.
Most people on my team do merges only. Everything is a trade‐off. We get along just fine.



…for now.
I mean, if you've never done a git rebase --onto a b c, then you haven't really used git, right?

[GuRuGeorge]

as always it depends, if you truly understand all the implications of the different methods, you should simply decide on the spot what is best. I use squash, regular merge and also rebase in my projects and so do my coworkers at my job. Using blank rules like " always squash" or whatever is only useful if you work with juniors, who need straight forward guidance, because you don't have time to evaluate what's best for them in the situation.

[ZaidAlshattle]

Really well explained, thanks for the video!

[majorhumbert]

Create small pull request and squash. Stack these smaller pull requests for larger features. In this way, you'll not end up with one huge squashed change.

[diggus]

Am I crazy, or is a squash merge actually a squash rebase since it doesn't lead to a merge (the resulting commit only points to one parent)?

[streamcyper]

Would it be recommended to do a rebase locally, pushed to git and then just a normal merge, or would it be ok to just do it on github?

[elzabethtatcher]

My team's branches are usually 10 to 50 "fix" or "work, you mf" commits and there is no real value in any of it. We always use squash and have no regrets. Personally I usually try to keep my commits meaningful, but it rarely happens. No really worth the effort imo.

[AlexPavy]

If a pull request is big you can always merge it and start a smaller pull request. I just don’t see the benefit of rebase ever. Git rebase should not exist. Rewriting git history should not exist.

[ktjlsfwjcb]

Always squash, never merge, very rarely rebase.

[jamoncitovideos]

Instead of using --force, try using --force-with-lease. This makes sure you do not overwrite something that was committed by others, that way you have extra safety instead of simply relying on your teammates not touching your feature branch