Git Commit Message

A well-structured project is not just as clean-code but also need clean version control. We are developers that sometimes won’t get serious on our commit message. Finally, end up in a mess, which is not easy to maintain.

In my experience, each company has a different git convention. The one that I found outstanding is <type>(<scope>): <subject>. I prefer to practice this on my projects since there is no standard convention.

The rule is simple. Each commit message has a type, a scope, and subject.

Template

Type

  • feat (feature)
  • fix (bug)
  • chore (maintain code)
  • docs (documentation)
  • style (reformat code)
  • refactor
  • test

Scope

The scope could be anything like a context, a functionality or JIRA reference. It must not contain spaces. In my experience, sometimes I don’t specify the scope if the context is unclear. Example: style: reformat code

Subject

  • use present tense: “change” not “changed” nor “changes”
  • no capitalize the first letter
  • no dot at the end

Example

style: reformat code
refactor: remove duplicated code
fix(db): fix filter address ignorecase
chore(ui): change background color to green
feat(api): add login and register api
feat(ui): add login screen

Practices

Git hooks

To respect our convention, we can hook a commit-msg. Then share this configuration file to members in the project.

#!/usr/bin/env ruby

message_file = ARGV[0]
message = File.read(message_file)

$regex = /(Merge|Release|((feat|fix|chore|docs|style|refactor|test)(\(.[^ ]+\))?:)) .+/

if !$regex.match(message)
puts ""
puts "[ERROR] Your commit message is not correctly formatted"
puts ""
puts "  #{message}"
puts ""
exit 1
end

An alternative way I found that interesting is commitlint, which also applied this convention.

Generate release notes

By following a good convention, we can easy to filter features, fixes to create a release notes.

Example: Extract all features

git log --grep "^feat" --pretty=format:%s

This way we can skip unnecessary commit like reformat code messages.

Although this page shows that we should not dump git logs into changelogs, a good convention can help to reduce the manual work.

Tags:

Categories:

Updated: