Committing in Git is The Future
Whatever you write in your git commit history is what you’ll be going back to at some point in the future to understand how the source code got to where it’s at now.
There are a couple of things that seem to work well when managing commits in git:
- Don’t have more commits than tell the story – so squash commits on a feature branch into a single final commit before merging
- Try to keep the tree clean – so rebase, or force master fast-forward merges, so the commit history of your main branch is a series of revertable individual commits
- Make your commit message tell their story well
Let’s look at the last one – the perfect commit message.
The Imperfect Commit Message
Don’t blether. Don’t treat it with disrespect. Don’t just commit with the branch name, and definitely look at http://www.whatthecommit.com/ for inspiration on what bad looks like
I just got:
A Great Commit Message
Here are some guidelines:
- Title the commit with a short, imperative statement, as though commanding the developer who made the change
- E.g. “Add support for versioned schemata”
- E.g. “Fix slow performance with multiple threads”
- Optionally, add some narrative underneath, perhaps in bullet point form
Good Commit Messages
Heading and Detail
Bad Commit Messages
A Who Cares Message
WHERE’S THE TEXT?
Vague and non imperative
Commit messages are only important when they’re important, at which point they’re mission critical. Getting your public commit history into a sensible shape, with pithy headlines, will give the optimum benefit to your future self and your code reviewers.