The wording might seems complex (I still had to think about what is "upstream" and "merge-base" since I'm not using this terms very often but the main idea the

The wording might seems complex (I still had to think about what is "upstream" and "merge-base" since I'm not using this terms very often but the main idea the author proposed is quite simple and brilliant if you know "how git works" and what "git reset" does. I don't do it but I like it a lot :) Probably many git users works like this because it all makes sense. The commands will look like that if you want to just squash your changes: git reset --soft $(git merge-base HEAD origin/master) git commit -m 'squashed commit` and like this if you want to squash and rebase on "upstream" (most likely "master" on "origin" remote), andrewmackrodt already wrote it in another comment: git fetch git merge origin/main git reset --soft origin/main git commit -m 'HN-1337 Awesome new feature' I like this approach (haven't tested it yet!) because as author wrote it doesn't unnecessary change much files in you current working directory, and IDEs sometimes get crazy when you do rebase. Currently, I usually try to write my individual commits to be logical changes grouped together and if I see there are some WIP commits or commits that don't look like one logical change, then I just squash this commits (not whole branch). This helps a little in avoiding unnecessary merge conflicts in rebase, but it's not always perfect solution. I still need to figure out what this "git rerere" magic does though...