I run squash-only repos. You can't just run a squash-only repo though; the practice is linked with things like trunk-based or branch-based development. More bro

I run squash-only repos. You can't just run a squash-only repo though; the practice is linked with things like trunk-based or branch-based development. More broadly, a single "thing" (feature/bug fix/task) needs to be done in a single merge. That gets tricky too - what about features being developed by multiple engineers? Generally, I create a branch that embodies the full scope of work and devs treat that as the default branch while working on it - merging their branches into that one. That branch needs to be consistently rebased to be kept up to date in order to avoid conflicts, and devs will sometimes need to merge or rebase their own branches based on that branch. Usually, this isn't too complicated, unless someone buries their head in the sand for a little too long (pun intended.) This also means that all CI jobs have to be configured to use the current branch rather than a static target - which makes logic a bit more complicated when dealing with things like E2E tests that create real environments. What does it accomplish? A linear, well-constructed history and it ensures resilient CI jobs. The other side of that, is that the real product branch gets a very organized history, while feature development branches can have non-standard commit messages like, "I screwed up", and can allow force pushes that can't be done on my default branches. This allows for both clean history and me to not be policing people's commit messages. If you value none of those things, it's a total waste of time and energy.