Which commit message convention do you use at work?

In order to create a useful revision history, teams should first agree on a commit message convention

Which do you use at work or personally?

Learn Something New Everyday,
Connect With The Best Developers!

Sign Up Now!

& 500k+ others use Hashnode actively.

Syed Fazle Rahman's photo

While it's difficult to follow the convention most of the time, I prefer the following:

<type>: <description>

[optional body]

[optional footer]

For example:

Feat: New comment faces

Show recent commenters in the postcard in the feed. 

fixes issue #223
Show +1 replies
Syed Fazle Rahman's photo

Co-founder & CEO, Hashnode

No, it's not defined by me. Tapas Adhikary There are many articles on the web that suggest this format. We try to follow this at Hashnode.

So far, we haven't rejected any commit/PR for not following a standard. We are a very small team. We discuss things when the commit messages or PR are not very clear.

Tapas Adhikary's photo

☝ UI/UX Enthusiast | πŸ’» Work @MicroFocus | ✍️ Blogger | πŸ‘¨β€πŸ« Mentor | 🎀 Speaker | 🍟 Foodie

Ben Buchanan (200ok)'s photo
JIRA-123 Concise description of the change
JIRA-123 Componentname: concise description of the change

Nice and simple... commit against a ticket number and write long form information there as required. Linking code changes to general systems is often required for compliance/change control reasons anyway.

In component-based repos, I might add a prefix specifying the feature being worked on. But more often than not I'll be including that in the description anyway.

I'm not a fan of essays in commit messages - if the information is critical to understanding the code it should be in a comment. If the information is relevant to non-devs, it needs to be exposed somewhere else.

Marco Alka's photo

In my current project, we use the following convention:

<issue-ID> <verb in present-tense> <rest of message (max 80 char)>

free text in body!

for example

JIRA-123: implement new set-group api
Mostafa Zaki's photo


Grey's photo

Fullstack Developer @ Asheori

Nice one... :-)

Gaponenko Andrei's photo

Most of the time it's simply something like:

JIRA-123 Removed the X & Added the Y to allow Z

When the ticket is going to be closed, all commits are force-pushed as a single one and the branch is deleted, so nobody's going to read your well-thought commit messages except you. That's why there's rarely even a description, unless I really think it's needed. If you want context, JIRA's ticked with a good description says it all.

Richard Saseun's photo

I use Andela naming conventions for

<type>(<scope>): <subject>``<BLANK LINE> <body> <BLANK LINE> <footer>


feature(comment):add comment feature

add comment feature to blog posts page using forums api
Josh Ike's photo
<type>([optional file name]): <short description>

<type <Simple / Indefinite Present Tense>> issue <issue ID>
Kleo Petrov's photo

I use two commit conventions, one at work, and one for personal projects:

At work, where we use Jira, we use the following convention:

<issue ID> - <verb> <description>


For personal projects, I try to follow the conventional commits :

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]
Hipkiss's photo
{what you've done - high level}

~ {this indicates a change to method/css/something}
- {this indicates a removal of a method/css/something}
+ {this indicates the addition of a method/css/something}

But I also use a branching strategy as well based on agile methodology.

Important to note I use gitkraken as well.

Show +1 replies
Tapas Adhikary's photo

☝ UI/UX Enthusiast | πŸ’» Work @MicroFocus | ✍️ Blogger | πŸ‘¨β€πŸ« Mentor | 🎀 Speaker | 🍟 Foodie


This is cool. My comment to Syed Fazle Rahman applies to you too. Hence not copy pasting :-).

Hipkiss's photo

Co-Founder, Founder, Entrepreneur & Problem Solver

Tapas Adhikary No worries. :). This is my personal method of commit messages.

I came up with it when i started my journey as a software engineer. For me, I've not found anything that could replace this system.

For additional context this is a high level of the branching strategy the company I work at and I utilise: We have story branches which are basically features and the branch looks like this story/{PROJECT_INITIALS}-{ISSUE_NUMBER}-{ISSUE_NAME}
So using My Awesome Project and issue or ticket number 134 (jira, gitlab, github, notepad) and the name could be Create landing page -
story/MAP-134-create_landing_page. Then this story gets split into smaller sub-tasks which are as trivial as possible. So, following the same convention as above, a sub-task would look like this:
Then sub-tasks get merged into their respective story which then gets merged into master for release.

cedric simon's photo

We go with:

verb(present tense) object


update header logo
Girish Patil's photo

I usually try to go with a convention which most of us follow at Hashnode

feature/patch/update/fix:Short description of the commit

Body: If any instructions/important info
NicolΓ‘s Parada's photo

For our Go back-end, we use golang's tip.golang.org/doc/contribute.html#commit_m..

Maneesh Kumar's photo

we follow the below approach

[Bug/Backlog XXXX]: Comment 
[Bug 8909]: implemented a new method to increase the performance.
miya bhai's photo

In component-based repos, I might add a prefix specifying the feature being worked on. But more often than not I'll be including that in the description anyway.

Mubarak  Aminu's photo

for personal project

type(subject): detail of the commit usually less than 70 words[status of feature]

for official work type(subject + ticket id): detail of the commit less than 60 work [status]

Want to read more?

Browse featured discussions

Β© 2020 Β·Β Hashnode