This commit message template that helps you write great commit messages and enforce it across your team.

.git-commit-template

# [<tag>] (If applied, this commit will...) <subject> (Max 72 char)
# |<----   Preferably using up to 50 chars   --->|<------------------->|
# Example:
# [feat] Implement automated commit messages

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

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

# --- COMMIT END ---
# Tag can be 
#    feat     (new feature)
#    fix      (bug fix)
#    refactor (refactoring code)
#    style    (formatting, missing semi colons, etc; no code change)
#    doc      (changes to documentation)
#    test     (adding or refactoring tests; no production code change)
#    version  (version bump/new release; no production code change)
#    jsrXXX   (Patches related to the implementation of jsrXXX, where XXX the JSR number)
#    jdkX     (Patches related to supporting jdkX as the host VM, where X the JDK version)
#    dbg      (Changes in debugging code/frameworks; no production code change)
#    license  (Edits regarding licensing; no production code change)
#    hack     (Temporary fix to make things move forward; please avoid it)
#    WIP      (Work In Progress; for intermediate commits to keep patches reasonably sized)
#    defaults (changes default options)
#
# Note: Multiple tags can be combined, e.g. [fix][jsr292] Fix issue X with methodhandles
# --------------------
# 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 "-" or "*" for bullet points in body
# --------------------

Easy, tiger, no need to be that irritated. I just wanted to point out that there is another variation that is almost the same out there. I wasn't making any claims=)

As I said I did not understand the purpose of the comment so I wanted you to clarify. Thanks for that.

It's just that at some point you came across a style guide and decided to tweak it,

You are right at some point I came across this gist which had a template I could use as is. That template however was not exactly what I needed, so I forked it and tweaked it to my needs.

instead of trying to search for a better variant that the community already had come up with (https://github.com/udacity/git-styleguide/commits/gh-pages/index.html).

1. I did search and I did find a number of different styles and templates and I chose this one because it fitted my needs.
2. I don't see how Udacity's version is a better variant. This is subjective.

And I need to mention that I've never worked for Udacity or using it as a learning platform, I don't even like them. But it's worth mentioning that it is easier to live in a world that has no "duplicated code".

Udacity provides a web page with text describing how a good git commit message should look like and gives a commit example at the end. There is no code provided, there is no git template provided, thus I don't see where the "duplicated code" comes from, nor how I would benefit.

If you trace the origin of this gist you will find yourself here, only to find out that the original version of this script was indeed almost identical to Udacity's style guide. You will also find out that it was first created on 2015-02-12 (while Udacity's style guide first appeared on github on 2015-07-22) and that it mentions:

# For a full example of how to write a good commit message, check out
# https://github.com/sparkbox/how_to/tree/master/style/git

which implies that it was on its own inspired by some other work. The link is no longer available but I suspect it pointed to this.

To sum up, I have no idea who came up with this style guide originally (I guess as most things it started by someone and got improved over time), but I am happy there are "duplicates" of it and that we are free to create more "duplicates" that better fit our needs.
For more standardized commit messages have a look at conventional commits.
Also I believe that one of the greatest things in free and open-source software (and culture) is that you are free to tweak things to your needs/liking and there is no need for everyone to agree on a single implementation.

I sincerely apologize if my comment offended you in some way. I believe you can delete my comments if you feel like it.

It was just not clear to me what you were trying to achieve with that comment, so I wanted to make sure I understand and act accordingly. There is no need to apologize, just try to better convey the reason behind a comment. There is also no reason for deleting any comments from a discussion.

Well, that is a good discussion. Thank you for pointing on conventionalcommits, I didn't know these guys=)

Well, Super template.

Thanks for sharing!

Thank you for sharing. I also incorporated it in my projects.

Thanks a lot🙂

Will this commit template also be reflected on the Github Desktop app? Any insights appreciated, thanks in advance.

@josueal1 I don't know about that. I am not using the Github Desktop app. If you give it a try let us know :)