This page describes how to phrase reasonable Writing reasonable git commit messages . We assume that you have already read and agreed in Commit rules!
Info |
---|
Reasonable commit messages facilitate: - Quickly reading the commit history
- therefore understanding the development history of a project at a glance.
- Reverting of commits are easy applicable.
And there are many other good reasons to write reasonable git commit messages |
Intro
Image Removed
How to start the message
Below you will find seven good rules to write great commit messages. But before, please remember this specific Magnolia rule(s)
helps fellow team members to read and understand a project's development history at a glance.
Following this facilitates several other activities, such as documentation, root-cause analysis or reverting changes.
Example
Subject
Body | MAGNOLIA-6223 Add improved API for resource change observation
- Introduce ResourceChangeHandler and ResourceOriginChange classes
- Deprecate ResourceOrigin#watchForChanges(...) API and add registerResourceChangeHandler API
- Provide protected method for lazy initialisation of underlying resource change monitoring mechanism
- Implement basic support in AbstractResourceOrigin and provide an adaptor of old API to the new one there |
General rule
As compiled by Chris Beams here and listed below, we follow the seven rules of a great git commit message. "Keep in mind: This has all been said before."
Info |
---|
TL;DR - Separate subject from body with a blank line
- Limit the subject line to 50 characters
- Capitalize the subject line
- Do not end the subject line with a period
- Use the imperative mood in the subject line
- Wrap the body at 72 characters
- Use the body to explain what and why vs. how
|
On top of these rules, mind the following Magnolia-specific guidelines:
Note |
---|
The subject |
Note |
---|
The subject of the commit message should start with the Jira ticket number, in the appropriate Jira project corresponding to the repository at hand. - All code changes must belong to a Jira ticket, even if it's they are "only" considered refactoring. If a ticket does not exist in the current project, please create it and link it as appropriate.
- Please avoid cross-referencing Jira projects from other repositories. This makes it hard to track changes, know when a module should be released, or which ticket/version introduced or fixed an issue.
- Commits only updating internal versions in webapps/bundles may use the motivating Jira ticket from that module, or simply no prefix at all, e.g. "Bump personalization to 2.1-SNAPSHOT".
- QA prefix may be used, but exclusively for 100% cosmetic changes, e.g. formatting, Javadoc.
|
...
...
...
- describes and summarizes well what you have done with the commit.
|
...
...
- issue summary in Jira may be a good starting point
|
...
...
...
The seven rules of a great git commit message
...
TL;DR
...
1. Separate subject from body with a blank line
...