Hard to tell.. I live by rules 8/9/10 [1] and some others to a lesser extent, but the emojis (which don't even come close to verbs describing what happens) make it quite funny.
[1]
8. Use the Present Tense ("Add feature" not "Added feature").
9. Use the Imperative Mood ("Move cursor to..." not "Moves cursor to...").
10. Use the Message body to explain what and why vs. how.
this guide doesn't use any fancy-unicodes...
I'm guessing that :penguin: isn't a unicode-penguin character, but some emoji supported natively by github
(e.g. :+1: means thumbs-up, but that's native to github / shows as :+1: to non-emoji-supported cli/browser/etc.)
I'm not a huge fan of mandatory emoji in commit messages either, but this is a poor excuse. A Git commit message can contain any sequence of bytes except for a NUL byte. It can even contain invalid UTF-8. Tooling that doesn't treat commit messages like this is dangerously fragile. God forbid anyone accidentally pastes “typographer’s quotes” or text with diacritics into a commit message and breaks the build.
On the plus side, I don't think this style guide will break your CI. It seems to be taking advantage of GitHub's text => emoji substitution, so other Git tools will just see the text form (eg. :sparkles:)
Emoji might actually be usefull for quick oversight, but how can you include a reference to an issue for every commit? What if you are just adding more tests?
I've seen this kind of thing work really well for some teams. In that case there should be a "ref" for adding tests.
It tends to act as resource management, you shouldn't be working on things that your manager doesn't know about at least enough to make an "issue" for it.
But it's not a 100% must in all cases, just that there SHOULD be a ref there. The rule of thumb for us was if it's going to take more than 15 minutes, it needs an issue.
Edit:
I can't seem to reply any more, but this is just for organization. you can create your own issue and work on it on your own, this is just a way to organize and categorize the commits and provide an easy "parsable" way to give some context to them.
> The rule of thumb for us was if it's going to take more than 15 minutes, it needs an issue.
Gross. That sounds like process for process' sake. Or you could, you know, just trust that your developers are working on actually useful things because that's what you hired them to do, and we're all professionals here, one hopes.
Maybe something like this is useful for _very_ junior developers who need a bit of hand-holding before they're steeped in how professional development in a team setting works, but if you still need this sort of thing after even a year at work, that'd be a huge red flag to me.
I like to keep Markdown away from my repos. After a while people get clever with their Markdown and it makes reading commit logs using command-line tools increasingly difficult. It also encourages writing things into commit logs that would be better suited for documentation.
Edit: apparently it's not a Github specific thing.
I tried and you're right. Did they disable that recently? Or is there a popular IDE that does render Markdown in commit messages? I had to ask a few people not to use Markdown and I just assumed it was a Github thing.
Please don't do this. :lipstick: :sparkles: has absolutely no meaning when I'm working in a clone of your project, on the terminal, without access to the Internet.
I think it would be great to standardize (or at least widely adopt) some conventions for commit messages, especially with respect to tagging that isn't easily expressed by the "FOO: Imperative bar" style. Let's do it with plain text, not cute icons that get rendered differently (or not at all) depending on the OS or client you're on.
"*" = [the projects or repos to which this styleguide applies is not defined > /dev/null]
:pencil:
"Use the Present Tense" == "'Use the Present Tense' is missing object. Please specify: 'Use present tense verb'"
"Rule 8 parenthetical example ()" == "Use present participle as descriptor; try 'Adding feature' NOT 'Add feature' to accurately describe what submitter does during ``git commit``"
"Use the Imperative Mood" == "Error: Imperative Mood does not map to correct structure; please check grammar and re-submit"
38 comments
[ 2.4 ms ] story [ 88.1 ms ] threadThough it probably should.
Ref 14585129
[1] 8. Use the Present Tense ("Add feature" not "Added feature"). 9. Use the Imperative Mood ("Move cursor to..." not "Moves cursor to..."). 10. Use the Message body to explain what and why vs. how.
I've seen CI systems broken because of Unicode in git commit lines... :-/
(e.g. :+1: means thumbs-up, but that's native to github / shows as :+1: to non-emoji-supported cli/browser/etc.)
On the plus side, I don't think this style guide will break your CI. It seems to be taking advantage of GitHub's text => emoji substitution, so other Git tools will just see the text form (eg. :sparkles:)
It tends to act as resource management, you shouldn't be working on things that your manager doesn't know about at least enough to make an "issue" for it.
But it's not a 100% must in all cases, just that there SHOULD be a ref there. The rule of thumb for us was if it's going to take more than 15 minutes, it needs an issue.
Edit:
I can't seem to reply any more, but this is just for organization. you can create your own issue and work on it on your own, this is just a way to organize and categorize the commits and provide an easy "parsable" way to give some context to them.
Gross. That sounds like process for process' sake. Or you could, you know, just trust that your developers are working on actually useful things because that's what you hired them to do, and we're all professionals here, one hopes.
Maybe something like this is useful for _very_ junior developers who need a bit of hand-holding before they're steeped in how professional development in a team setting works, but if you still need this sort of thing after even a year at work, that'd be a huge red flag to me.
If this is a joke, eh it's not a great one.
If it's actually for real, might I suggest making a script for the emoji selection and the formatting of "Only One Newline"?
https://github.com/jakeasmith/commit
And why not emojis? They just won't be rendered where they aren't supported.
I like to keep Markdown away from my repos. After a while people get clever with their Markdown and it makes reading commit logs using command-line tools increasingly difficult. It also encourages writing things into commit logs that would be better suited for documentation.
Edit: apparently it's not a Github specific thing.
But :checkered_flag: for Windows? I think this is problematic. To me it looks more like an icon that suggests "finishing" something.
That's the problem with icons, their meaning breaks down rather fast if you can't create specific ones.
I think it would be great to standardize (or at least widely adopt) some conventions for commit messages, especially with respect to tagging that isn't easily expressed by the "FOO: Imperative bar" style. Let's do it with plain text, not cute icons that get rendered differently (or not at all) depending on the OS or client you're on.
(Edit: Here's a link to a style guide in git's documentation, for example: https://www.git-scm.com/book/en/v2/Distributed-Git-Contribut...)
Using emojis and limiting yourself to 50 chars is really difficult
Edit: Just seen that "Every Raw Emoji Text(:emoji:) is Counted as One Char!" - Great! But I'm not sure how Git CLI will like that.
"*" = [the projects or repos to which this styleguide applies is not defined > /dev/null]
"Use the Present Tense" == "'Use the Present Tense' is missing object. Please specify: 'Use present tense verb'""Rule 8 parenthetical example ()" == "Use present participle as descriptor; try 'Adding feature' NOT 'Add feature' to accurately describe what submitter does during ``git commit``"
"Use the Imperative Mood" == "Error: Imperative Mood does not map to correct structure; please check grammar and re-submit"