If you’re paying attention, you’ll remember that just yesterday I told you I hate squash.

Now I love it?

So I still hate squash-merging.

But I’m a big fan of selective squashing.

I think this helps answer a question I got in response to yesterday’s email (keeping it anonymous, as I haven’t asked permission yet to share the name):

What do you recommend if you must push to the remote to test changes (e.g. in CI/CD development?). You can end up with a number of commits which do very little, but the quality of each message is not necessarily poor.

This is one example where selective squashing is very appropriate, in my opinion.

Other examples can be fixing typos or small bugs.

Given a PR with the following commits:

• 00509ca7 Add amazing feature
• 60b725f1 typo
• 0c9c85c7 typo
• 0d97880d bug fix
• fe8191b3 spelling
• c9cb60b2 ???
• 3b5d5c37 argh
• 12955042 fix
• 21231617 i’m stupid
• 3ccf37be typo
• ed5084dc Profit!
• 3b5d5c37 Fix linter failure discovered by CI
• 12955042 Set execute bit on CI script

You can squash the related commits manually. This is usually done with git rebase -i (-i for interactive), with a much friendlier result:

• 00509ca7 Add amazing feature
• c9cb60b2 ???
• ed5084dc Profit!

You can also use git commit --amend if you know that the commit you’re about to make should be part of the previous one, rather than a stand-alone commit.

Interactive rebasing also allows you to re-order commits (possibly before squashing). And I also find myself using lazygit a lot to help with such rebasing and squashing.