How to Close a Pull Request - Merge Commit vs Squash vs Rebase on GitHub

On GitHub, you have three different strategies for closing a Pull Request: Merge Commit, Squash, and Rebase. Merge Commit is the most common so far but is it always the best one? Let's see all of them in action to get some more context, plus some extra tips at the end!
_______________________________

Hit like and subscribe for more content! :D

You can also follow me on the other platforms:
_______________________________

#github #merge #rebase #squash #pr

[ThioJoe]

The demo of the rebase was helpful thanks

[muhamedkarajic]

Tnx. Really simple and streight forward.

[lapppse]

thank you for the video! it was interesting to know about the squash

[lgic]

Back in the day I would always do a rebase... We had a large code base with many devs doing various things... Being very newb I wanted my changes pulled forward and tested. I always made a commit message and thought my commit log didn't go with -- woops!

Maybe I did know that it went but forget now... Either way....

[Han-veuh]

2:04 says con of squash commit is losing history on branches?
Is this true, or it assumes feature branches are deleted?
Because after a sqaush merge, github->insights-> network still shows the commits that went into the squash commit. They are not lost.

Some feedback:
It's not clear when speaking of commits, are you talking about the contents, or the commit SHA. Contents can stay the same but new SHA are created.
1. 2:24 when describing squash merge, an extra commit was added
2. 3:39 when describing rebase merge, no extra commit was added. This may cause people to think the commit SHA wil stay the same. To be consistent with 1, i expected 1 new commit to be added per moved commit (so 2 in this case) OR to clarify whether you're describing exact SHA or the contents (code/file changes)

[abrahama]

nice, now i got a better understanding of those commits. And love the Demo Time! No code.

[DavidKoleckar]

why it is called squash and merge and not squash and rebase?

[AaronJaeger]

I like squash when I have to do a ton of tiny commits when I am debugging or working through trial and error cycles.

[mklueh]

I'm currently facing a bit of trouble using squash when I merge from develop to master. Whenever I do that, and merge the master back onto develop, with the next pull request the old commits re-appear that were already squashed. I guess that's the case because develop still contains the full history which is squashed again and again. So my question would be, should squashing only be used for feature branches and rebasing for develop -> master merges? Or how else would I get a clean history on master without duplicated commits in pull requests?

[AaronJaeger]

"... all your sins will be forgotten." 🤣

[saepudinepul]

how to squash commit 'pushed' and 'locally' ?

[tommyholmberg]

In my opinion always use squash. If you use continous integration your branches will hopefully not live for a long time anyway.