Commit to Review

  It starts, as these things often do, with a tweet:

Sadly, the most common model for commit history as documentation is "chaotic mess that doesn't give you any information without deep study"

— Sarah Mei (@sarahmei) September 16, 2017

  Which led me on to saying:

Reluctance to rebase and force push prevents commits being reviewed like code. If commits don't make sense to others, change them! https://t.co/PZ8isWR3HA

— Andrew Morton (@TestingChef) September 16, 2017

  Because there are many ways of using and abusing git rebase, I thought it a good idea to explain the use case I'm referring to in more detail.

  We work on branches, and once we've got them to the point where the work can go into master, we raise a merge request for it. This merge request acts as our code review stage. Questions will be asked, improvements will be made and it'll eventually be merged. My suggestion is, just before the merge is done, this is where an interactive rebase (or squash or amend, whatever change to the history is appropriate) and force push should be done in order to get the commit history clean.
  You often see commits that just say "typo" or "bug fix". If you are really lucky, you get a commit that actually has a message body, but often it is describing what has been done, not why it was done. By being able to review commit messages, point out these issues and have them be fixed, you will be teaching and learning what makes useful commit messages, and your log will be an easy to read story of the changes made.

  Code reviews are a way people learn to write good code. How are people going to learn how to write good commit messages if they can't also be reviewed?

P.S. My go to guide for how to write commit messages is by Chris Beams and can be found here