Forums
Thread
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?
Responses(16)
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]
For our Go back-end, we use golang's tip.golang.org/doc/contribute.html
we follow the below approach
[Bug/Backlog XXXX]: Comment
example
[Bug 8909]: implemented a new method to increase the performance.
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
<type>([optional file name]): <short description>
<type <Simple / Indefinite Present Tense>> issue <issue ID>
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)]
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.
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
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
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.
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.
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
Samuel C. Tyler
Linux, Ska, and Cooking!
I've been using the same convention for over a decade, and it works with a lot of different agile tools:
Here is an example:
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.