|# [<tag>] (If applied, this commit will...) <subject> (Max 72 char)|
|# |<---- Preferably using up to 50 chars --->|<------------------->||
|# [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|
Ahahah yes indeed a way to look at it ;-)
On a more serious note that's exactly the reason for which I've downloaded the template and pushing my colleagues to do the same, that will be the hard part.
Well, I just forked it from https://gist.github.com/adeekshith/cd4c95a064977cdc6c50 and tweaked it to my needs so credits go to the original authors ;)
Stumbled upon this gist trying to find a way to have
I don't understand what's the purpose of your comment.
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=)
It's just that at some point you came across a style guide and decided to tweak it, 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). 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".
I sincerely apologize if my comment offended you in some way. I believe you can delete my comments if you feel like it.
As I said I did not understand the purpose of the comment so I wanted you to clarify. Thanks for that.
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.
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:
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.
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.