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?

Start a personal dev blog on your domain for free and grow your readership.

3.4K+ developers have started their personal blogs on Hashnode in the last one month.

Write in Markdown · Publish articles on custom domain · Gain readership on day zero · Automatic GitHub backup and more

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

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.

Mostafa Zaki's photo

1_m90z3NIz15R6MrSc-5fYmw.png

Grey's photo

Nice one... :-)

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
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.

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>

<body>

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

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]
Richard Saseun's photo

I use Andela naming conventions for

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

Example:

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>
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
Hipkiss's photo
Title:  
{what you've done - high level}

Message:  
~ {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

Hipkiss,

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

Hipkiss's photo

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:
sub-task/MAP-135-create_navbar_item.
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

Example:

update header logo
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 
example 
[Bug 8909]: implemented a new method to increase the performance.
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]

Samuel C. Tyler's photo

I've been using the same convention for over a decade, and it works with a lot of different agile tools:

[<ticket action> TIcket Number] action, in the imperative form (<ticket action> <additional ticket numbers>)

If my code isn't descriptive enough or the ticket doesn't cover enough
of why this code should be implemented this way, I write a little bit more
in the long description, although this is a rarity.

Here is an example:

[starts API-1234] refactor user widget to show avatar [wont-fix API-4356 blocks API-2543]

Adding the avatar here blocks the ability of the user to see the logo (API-2543)

I rarely use the long description due to better tooling and code design. If my code is self-documenting and my tooling allows me to see all changes in a commit easily, I should be able to discern the reason for any particular change without much effort, if any.