The problem, at least for me, is not the merge commit. They are indeed easily ignored. The problem is, that I don't want to see a dozen commits fixing typos or trivial bugs.
One trick that can really help with this is `git commit --amend`, which allows you to amend the last commit. If you encounter a bug or a typo in the your last commit, add your fix to the index and then do `git commit --amend`. This will replace your last commit with a new one that contains your latest fix. Of course, this should only be done if you did not push your last commit to remote.
For fixes to earlier commits, I don't bother much, and just live with the trivial commit. Though if I end up making several trivial commits in one setting, I do a cleanup and merge this fixes in one commit before pushing.
We use feature branches and rebase before merging to master (mostly for the reason stated above - keep things clean and treating the branch as a single logical unit, not caring about higher-resolution history within the branch).
However, some times, especially since we typically merge on Github from a PR, it's easy to forget to rebase, or notice that there are more commits. So our history is mostly clean, but occasionally contain some "messy" commits.
I know we can reset master, but it feels a bit too risky compared to living with a bit of noise when mistakes happen.
Anyone knows of some way to prevent / alert / notify or otherwise help us avoid this rather common mistake before it happens?
This also has the benefit of complaining if someone else has force pushed (changed history / removed commits) to upstream/master.
Catch it early.
https://leanpub.com/sanegit (I consult/train on this in SF/Bay area.)
There is an indicator for the number of commits and you can view each one individually, but somehow it's so easy to forget.