[liquidise]

I do not understand the appeal of squashed merges. The only pro i know of is the ease of reverting a merge. On the cons side: you obfuscate an entire branch into a single commit, effectively making git-bisect useless. Furthermore, if multiple people collaborate on a branch, all code blames to one person, quite literally rewriting the code history.

[nhumrich]

Its designed more for people who do master-based development and do a PR per commit. (But might add a couple commits fixing the PR)

[SOLAR_FIELDS]

It's going to be highly pipeline, workflow, and team interaction dependent. In my place of work you generally only have one person working on a branch to add small, modular features. For releases we cut master into release branches. We fairly frequently need to downstream a commit from master into the staging branch and more rarely the production branch. The squash allows for a quick and easy cherry-pick of the feature to apply downstream.

If the code change is not widespread, I would always encourage a squash. Commits to two different parts of the codebase that do not directly rely on each other on the other hand should remain separate.

[zenlikethat]

Squash merge would be most useful in cases where someone turns in a PR and then there's back and forth which result in them making additional commit such like "Fix typo" and "Change struct name". That's not useful history and it's sometimes easier just to squash merge rather than give the contributor a lesson on reabse every single time. Naturally you shouldn't squash if the history needs to be cleaned up manually but it's rare to have multiple authors on one PR.