"But it is littering the commit history with useless commits!" is what I always hear
With `git amend` and `git fixup` you can arrange your commits to be clean, properly documented and self explanatory (and maybe atomic but that's a little harder). It takes a little time but it is hugely beneficial to code reviews and bug investigation.
(Our workplace has a mix of github flow, which is one branch per PR: https://docs.github.com/en/get-started/using-github/github-f... ; Atlassian Gitflow https://www.atlassian.com/git/tutorials/comparing-workflows/... ; and the completely different Gerrit flow which ends up very rebase and amend heavy: https://gerrit-review.googlesource.com/Documentation/intro-g... )
Nobody should be able to force-push to master (or any public branch) except on specific occasion. In that case, someone is authorized, performs their specific action and then get de-authorized.
This is pretty basic.
Usually when using the commands directly they're more careful, but have the mindset "an IDE wouldn't intentionally break something so this button must be safe to click".
IDEs in particular should expose the details all the time, and show the command that's being run, so it can teach people passively instead of misleading them and leaving them stuck when it breaks.
making commits atomic is harder because we tend to just write code, without first breaking up the requirement into atomic pieces
Don't push half-baked work on other people! You waste their compute cycles needlessly, from now until the end of time.
I.e., git can retain two representations of a sequence of commits: the original sequence, and also a larger commit that (a) produces the exact same code change as the sequence, and (b) has its own commit message.
For viewing history you can use "git log --first-parent" to view only those merge commits, which should satisfy the people who love a linear history, without actually losing the intermediate commits.
Then I remember that I have enough trouble getting a few dozen people together to write well formed and understandable commit messages for one level of commit messages alone. This scheme would require people to extend more energy on constructing commits which is at best something very few care about.
Then there are tickets and other corresponding information, but they could rot for all I care, as they so often do, unless a decent commit log is in place.
(I'm surprised this got a downvote when that's how we got here: a situation in which a change was ""hidden"" in a merge commit that would have been explicit in a rebase workflow)