Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

Table of Contents

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."

TL;DR

  1. Separate subject from body with a blank line
  2. Limit the subject line to 50 characters
  3. Capitalize the subject line
  4. Do not end the subject line with a period
  5. Use the imperative mood in the subject line
  6. Wrap the body at 72 characters
  7. Use the body to explain what and why vs. how

On top of these rules, mind the following Magnolia-specific guidelines:

Tip
  • 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.

...

  • Make sure

...

  • the subject

...

  • describes and summarizes well what you have done with the commit.

...

  • The title/

...

  • issue summary in Jira may be a good starting point

...

  • , however

...

  • do not just copy paste!

...

The seven rules of a great git commit message

...

TL;DR

...

1. Separate subject from body with a blank line

...