Write commit messages so that:
- they complete the sentence “This commit will…”
- the commit log can be understood by your Product Owner
- they describe the “why” — because the “what” can be read in the diff
For example:
Make the sign-up button look like all other calls to action Ensure the timezone is always correct on UAT Allow clients to retrieve the time when an application is rejected
instead of:
Import the new LESS file on the home page Updated config Updated endpoint for rejected
Nice commit messages is something I still struggle with.
However do you think Product Owners want to look a commit messages?
Hi Federico,
One reason for writing commit messages in this way is that it creates opportunities for non-developers to read them. For example, it becomes possible to use the commit log directly in release notes.
Good point. I tend instead to write very small commits, for things that do not necessarily produce a visible effect for the user alone. However I “tag” issues described in the issue tracker.
E.g. “issue41: “.
Later Project Owners can see a few commits in a row all related to issue 41 and go look there for a user-oriented description of the feature.
I guess I could later squash all the commits related to the issue41 and write a single, high-level message (several people prefer that), but I prefer to keep very granular commits in my history.
Pingback: Java Web Weekly, Issue 122 | Baeldung