This commit message template helps you write great commit messages and enforce it across teams.

.git-commit-template.txt

# <type>: (If applied, this commit will...) <subject> (Max 50 char)
# |<----  Using a Maximum Of 50 Characters  ---->|


# Explain why this change is being made
# |<----   Try To Limit Each Line to a Maximum Of 72 Characters   ---->|

# Provide links or keys to any relevant tickets, articles or other resources
# Example: Github issue #23

# --- COMMIT END ---
# Type can be 
#    feat     (new feature)
#    fix      (bug fix)
#    refactor (refactoring production code)
#    style    (formatting, missing semi colons, etc; no code change)
#    docs     (changes to documentation)
#    test     (adding or refactoring tests; no production code change)
#    chore    (updating grunt tasks etc; no production code change)
# --------------------
# Remember to
#   - Capitalize the subject line
#   - Use the imperative mood in the subject line
#   - Do not end the subject line with a period
#   - Separate subject from body with a blank line
#   - Use the body to explain what and why vs. how
#   - Can use multiple lines with "-" for bullet points in body
# --------------------
# For updated template, visit:
# https://gist.github.com/adeekshith/cd4c95a064977cdc6c50
# Licence CC

To apply the template,
Save the above file to your local machine and use
git config --global commit.template <.git-commit-template.txt file path>
For example, if you saved it to your home folder, try:
git config --global commit.template ~/.git-commit-template.txt

References

• A useful template for commit messages
• How to Write a Git Commit Message
• Example for a Good Commit Message

If you allow empty commit messages set

git config --global commit.cleanup strip

To prevent git from using the template as the commit message.

It would be cool to see this automatically done a la this blog post

@jwolff52 a PR template and a git message template are very different things. Because a PR template takes effect after you have committed I dont see how that would work.

This is super awesome, we use it now with https://github.com/lennym/commit-template and husky

In all my searching no one has explained the type reasoning. I am guessing it it for some kind of overview. However in my experience the distinctions between feat, fix, etc. are contextual and require more information to grok them. I have found that they become meaningless shown on their own in the --online logs. It isn't till I expand the commit messages and look at the --stat or body of the commit message do I gain any insight to the meaning of the type. Suggesting that it does not provide an actual benefit to its placement in the subject line. Maybe there is a perceived benefit but I haven't experienced one yet.

Considering it takes up valuable characters to the 50 I wish my subject lines to fit within and the fact that I have experienced subject lines that could not be realistically smaller then 45 - 50 characters without losing valuable context I personally avoid extra cruft like adding a type. Mainly because its use is required otherwise it looses its perceived value. In contrast using emoji is optional if there is room.

I'm asking the wider community how the type requirement helps where a git log --grep feature fails?

@sukima - see https://conventionalcommits.org/ for an explanation of the various types of commit. If you are using semver, many tools (lerna, for example) can automatically apply version updates based on git log messages since the last release.

try in my server 🗡️

do you have the script to reject invalid commits?