Git Commit Squashing Debate

Do you not make a big mess of commits, then selectively squash before submitting a PR?

Squash and merge, to keep the commit history clean. You can always dig up the PR to see commit by commit how it happened if you must. We've only done this in my organization... maybe twice in five years. Personally I don't work elegantly enough that my commits represent some coherent narrative anyway, and it hasn't caused enough issues in my job for me to change my ways now.

Squashing commits into one mega-commit isn't great for future investigations of the commit history (code review, bisects etc). It is much better to create separate logical commits, rebase them and pull in the result, either as a branch fast-forward merge, or with a merge commit where appropriate.

Please no. Squash and merge means that when someone (maybe you) comes across a strange-looking line of code in 18 months and uses git blame to figure out why it was added, they'll be presented with a 1500-line wall of text with no context.Commits are a tool. Learn to use them.

Lots of commits. Squash merge the PR (github feature) to clean up the commit history.

I usually squash my commits before merging, i think that makes things easier while still keeping the chronological view intact

git rebase squash as a single commit on a single main branch is the one true way.I know a lot of people want to maintain the history of each PR, but you won't need it in your VCS.You should always be able to roll back main to a real state. Having incremental commits between two working stages creates more confusion during incidents.If you need to consult the work history of transient commits, that can live in your code review software with all the other metadata (such as review com

To me, the ability to bisect is a good reason not to squash (I assume you mean squash merge?).My commits all stand alone; each is a distinct change that pretty much always is in a working state. Often it will be a series of refactors before the real change. Ironically, though it makes bisect easier, I find it rarely need to use bisect: just looking at commit messages (via either log or blame) is often enough to isolate a problem.I accomplish this using interactive staging, and within my br

As someone who is a big proponent of "squash and merge" I am susprised to see myself labeled an extreme clean freak! I don't have very extreme git uses or opinions.I want a few things in my team's workflow:* A commit history that a human can mostly understand* Effective code reviews where I can easily see what changed between rounds* The ability to revert a whole Pull Request easily and cleanly* A local workflow that does not get in my way and allows me to be m

I personally prefer merging via squash since it keeps a linear commit history without polluting the history with tons of intermediate work-in-progress commits.A linear history is helpful when debugging since it makes git bisect a lot easier. Having individual PR commits in the history makes git bisect useless since it’s unfortunately common for individual PR commits to leave the system in a broken state.