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.
slightly OT, but I wonder if anyone has an answer for this.
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?
I recommend regularly updating your branch of master via fast-forward. That way if you are working with a slightly different git history, git will complain loudly (refuse to update).
This also has the benefit of complaining if someone else has force pushed (changed history / removed commits) to upstream/master.
I guess it's unclear what you meant by "mess". Some companies think training their devs is worthwhile, especially after losing days/work/$ through git messes. :)
The commits aren't bad as such, just noisy, typically. Github gives you a nice diff of the whole branch against master, so we normally don't pay attention to individual commits. We look at the change as a whole before merging it.
There is an indicator for the number of commits and you can view each one individually, but somehow it's so easy to forget.
Yes, that's one possible solution, but feels like we're punishing ourselves for every merge for the sake of avoiding a reasonably-rare issue. We're reviewing PRs on github, so it's much more convenient to merge them on the spot.
