Better Git Commit Messages

Length

There are actually two different lengths to consider. Git commit messages consist of two parts — subject and body.

Rework @propertysource early parsing logicRework the @propertysource parsing logic recently changed in commit
7c60888 to deal with the same source appearing on a @configuration
class and an @import class.
Processing now occurs in a single sweep, with any previously added
sources being converted to a CompositePropertySource.
Issue: SPR-12115
Rework @propertysource early parsing logic
filetype indent plugin on

Language

Make sure you don’t have unnecessary spelling mistakes in your commit messages. Or bad grammar. Or abbreviations or jargon that other people might not understand.

  • Add README.md file
  • Refactor sendMsg() method
  • Fix email template
$ git commit -m"Add README.md file"

Conventional commits

It might make sense to follow something like Conventional Commits specification.

<type>[optional scope]: <description>

Explain what and why, not how

The code itself explains how, so if someone wants to know, they can read the code. Git commit messages should deal with what (the subject line) and why (the body).

Issue: SPR-12115

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store