Git commit message 💬

I either use the conventional commits specification or just type what describes the commit best.

I have a template for Git commit in work which mentions the pattern of issue ID then it can be checking crossly with issues management tool by just a click, but just use the simple message for my personal stuffs.

There are rules how to write them correctly by design of git, they are probably invented by Linus Torvalds author of git.
The message should look like this:

short sentence that describe the change

Detail description why the change was needed. You don't need to write
what was changed since that is inside the commit itself. But rationale
is important, so you can benefit why the change happen.

also the first sentence should be shorter (not sure exactly how many characters).

I'm trying to write commit message like this if there are reason why something was changed. This is important specially with big projects and lot of changes where you don't know other part of the code. The message should be the clue.

A while back I adopted this format for an angular project, which is basically the Angular commit format It became muscle memory and has essentially become my standard.

<type>(<scope>): <subject>
<BLANK LINE>
<description>

I always start with a short and descriptive sentence -- including a period -- which still makes sense if prefixed with "Apply this commit to ". The only exception being the very first commit which can be something like "Initial commit." This requirement is incompatible with adding Issue ID/category/scope/whatever prefixes to commit messages. I don't think they add any value and they usually just end up being a distraction when you're looking at a list of commits.

After the short, descriptive sentence (and a blank line) you can include whatever you like in more detail. Use Markdown if you want formatting, but consider whether it's really important in this context. I generally only use asterisks for unordered lists when I want to detail several changes in a commit. Issue IDs/categories/scopes belong here, possibly in a block of YAML at the end.

a couple of things:

• there is a sparrow plugin which makes it possible to reject commits with syntax errors in commit messages - sparrowhub.io/plugin/git-commit/0....

• in combination with "git-commit" plugin you can use "git-current-branch" plugin to inject a branch name into every commit message - sparrowhub.io/plugin/git-current-b...

The whole flow is available through the Tomtit task runner - github.com/melezhik/Tomtit#profiles

 tom --profile git
 tom commit
 tom push

Or

 tom git-publish

My format is:
git commit -m "$SUPPORTING_EMOJI:$TYPE_OF_COMMIT: $COMMIT_DESCRIPTION"

With a few exceptions, I'm another one conditioned that the first line is a command: "Fix the parsing," "Begin implementing lighting feature," and so forth, and should fit in sixty characters, so that it (mostly) won't wrap when people check the logs on a console. After the first line, it's a free-for-all.

That said, the right answer is always "whatever the shop does," because we're cooperating on projects, not off doing our own things and just hoping they fit back together.

I have had a few projects where it was required to follow these rules: chris.beams.io/posts/git-commit/

Basically boils down to having an imperative statement with no period that is less than 50 characters for the subject and then lines of 72 characters or less for the body with subject and body being separated by a blank line.

Of course, ending with an Issue #XXX when relevant to tie the commit to an issue on GitHub.

After doing it that way for a bit, I now mostly follow a similar structure for most commits on all projects.

[PROJECT-TICKET] Tasks completed in present tense