It’s irrational, but I always stand on the sidelines of these conversations being a little bit cross that people slag off rebasing. At some point someone point

It’s irrational, but I always stand on the sidelines of these conversations being a little bit cross that people slag off rebasing. At some point someone pointed out that rebasing changed the history and if you change the history of a public branch everyone was going to have a bad time. That got turned into “rebasing is bad” and now people keep rolling it out the same old trope. It’s a tool, and a good one for managing your work. If you don’t know how to use it then you’re doing yourself a disservice. In terms of squashing, my rule is that I squint at the PR and if the commits are going to have value in a years time then I’ll merge commit otherwise I’ll squash. In 10 years of running my codebase I’ve never blamed and thought to myself “I wish there were more fine grained commits here” so it’s obviously working fine for me. As you say, do what works for your team but make sure you understand the tools and what they provide for you.