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?

Comments (19)

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 all replies
Tapas Adhikary's photo

☝ UI/UX Enthusiast | 💻 Work @MicroFocus | ✍️ Blogger | 👨‍🏫 Mentor | 🎤 Speaker | 🍟 Foodie

Syed Fazle Rahman ,

Cool!

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

cedric simon's photo

We go with:

verb(present tense) object

Example:

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
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 all replies
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:
sub-task/MAP-135-create_navbar_item.
Then sub-tasks get merged into their respective story which then gets merged into master for release.

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]