Git commit message 💬

Hello, there 👋🏼 I hope you are doing well.

As a developer, I know you are well aware of the Git version control system.

Just wanted to know:

How do you write your ▶

git commit -m "commit message"

Do you follow any special rule or something?
Let's discuss in the comment section below 😄

Comments

[shadowtime2000]

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

[Jayesh Tembhekar ⚡]

This is nice 👌🏻

[Vuong]

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.

[Aftab Syed]

What template are you talking about and how do you implement/incorporate that template when committing the code?

[Vuong]

thoughtbot.com/blog/better-commit-... here is a tutorial. My template is just put the prefix string like ABC-, then whenever I commit code, I just put the number sequentially defined prefix and also commit message at the end.

Git commit template is also affected to Git-familiar-tools like VScode/Fork.

[Jakub T. Jankiewicz]

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.

[Curtis Lawrence]

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>

[James Sinclair]

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.

[Alexey Melezhik]

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

[Shrihan]

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

[John Colagioia (he/him)]

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.

[Frank Corso]

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.

[Mo Ali]

[PROJECT-TICKET] Tasks completed in present tense