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

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?

@sukima type is particular useful in the context of a project that later can become a business. It helps with CAPEX (tech capitalisation) for tax purposes where you can deduct 'features' as investment and certain bugs as losses and so on.

@sukima type is particular useful in the context of a project that later can become a business. It helps with CAPEX (tech capitalisation) for tax purposes where you can deduct 'features' as investment and certain bugs as losses and so on.

Huh, TIL. Thanks.