[lukicdarkoo]

The squash and merge button is convenient, but not the only way. As you mentioned, sometimes I do squashing locally into multiple meaningful commits. It's important that my mess doesn't end up in the main branch. Also, another approach would be creating smaller pull requests.

[juped]

the size of your branch doesn't matter, if it really is logically separable into a lot of changes. what matters is usefulness to the future reader (you, or someone else). lowering the number of commits for its own sake makes things less useful, not more, by destroying useful information.

you are correct to realize that e.g. "my working directory as of this timestamp when i got up from my computer" is not useful information, and should not be published. however, a diff that does too many things at once is also not useful information - you are forcing the reader to separate it themselves, possibly wrongly, every time they read the diff. very few branches in actual practical work are organically one commit long in their most useful expression.

finally, the merge to upstream is useful information, as the only source of a high-level view of the progression towards a release, and if you (i'm only guessing because of the use of the "clean history" shibboleth) avoid actual merges (with merge commits) to upstream, you're destroying important information about the integration work of the project, making the history significantly messier (from the perspective of someone reading it, which is the only perspective that matters).

(at the advanced level of writing-history-for-usefulness, you also realize that random-place-on-master branch starting points are not useful information, and learn where to start them from, but this is low-impact in comparison to not destroying branches. still, learning things like "base a bugfix on the commit that introduced the bug" are real force multipliers.)