But surely you would like to squash those merge commits as well, at some points? Hundreds of merge/squash commits pollute the history almost as much as thousands of normal commits, so after a large feature set is done, one should just squash all of it into a single commit.
That way, you can have "nice" development history where tags for the old versions are redundant since they match commits one for one:
$ git branch
main
$ git log --oneline
abcd000 (HEAD -> main) version 5.2
abcd111 version 5.1
abcd222 version 5.0
ef01234 version 4.7
9876543 version 3.4
fedb123 version 2.12
dedc456 version 1.128
The git log isn't a release history, it's a development history. Squashing commits throws away context that could be useful in any number of ways.
There's nothing wrong with squashing a bunch of commits that really should have been a single commit from the start:
- Update X to do Y
- Fix typo in X
- Add "foo" option to X for when Y is a bar
But most of the time "features" consist of many changes: we add one function we're going to need, then another, then yet another... Then we change an API to expose the new functions, then extend the UI to make room for it and finally make put it into the application and pull all the strings together.
Squashing all these into one commit is just a bad idea. You can always do git rebase -i before merging to do minor fixups or even reorder your commits (like when you notice a typo after several other commits), but completely removing all granularity... just no.
That way, you can have "nice" development history where tags for the old versions are redundant since they match commits one for one: