Skip to content

2. Commit Message

mukunzidd edited this page Oct 10, 2022 · 2 revisions

A commit message consists of a header, a body and a footer, separated by a blank line.

Any line of the commit message cannot be longer than 100 characters! This allows the message to be easier to read on GitHub and in other various git tools.

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

These rules are adopted from the AngularJS commit convention.

Message Header


The message header is a single line that contains a succinct description of the change containing a type, an optional scope, and a subject.

#####<type> This describes the kind of change that this commit is providing.

  • feat (feature)
  • fix (bug fix)
  • docs (documentation)
  • style (formatting, missing semi-colons, …)
  • refactor
  • test (when adding missing tests)
  • chore (maintain)

#####<scope> Scope can be anything specifying the place of the commit change. For example events, kafka, userModel, authorization, authentication, loginPage, etc...

#####<subject> This is a very short description of the change.

  • use imperative, present tense: “change” not “changed” nor “changes”
  • don't capitalize first letter
  • no dot (.) at the end

Message Body


  • just as in subject use imperative, present tense: “change” not “changed” nor “changes”
  • includes motivation for the change and contrasts with previous behavior

http://365git.tumblr.com/post/3308646748/writing-git-commit-messages

http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html

Message Footer


Finished, fixed or delivered stories should be listed on a separate line in the footer prefixed with "Finishes", "Fixes", or "Delivers" keywords like this:

[(Finishes|Fixes|Delivers) #STORY_ID]

Message Example


feat(kafka): implement exactly once delivery

- ensure every event published to Kafka is delivered precisely once
- implement error handling for failed delivery

[Delivers #130635935]
Clone this wiki locally