DEV Community

loading...
Cover image for How much effort do you put into commit messages?

How much effort do you put into commit messages?

madza profile image Madza ・1 min read

Are you the 'lazy' type and often write them poorly and unorganized, with no proper explanation of the action and later have trouble navigating in the version tree?

Or do you always put in time and effort, trying to come up with meaningful, easy to understand git commit messages, and push them only when reaching reasonable milestones (finishing updates, adding features, changing the design, etc)?

Personally, I still have to learn to master this too, and, when it comes to the second case, some time ago I came across a nice comment by @devmount , so I decided to share and maybe some of you could find it useful:

Short and clear, thank you for this article!
I tend to use emojis for the type - it shows the type of the commit at first glance, e.g.:

:heavy_plus_sign: when adding a file or implementing a feature
🔨 :hammer: when fixing a bug or issue
💚 :green_heart: when improving code or comments
:zap: when improving performance
📜 :scroll: when updating docs or readme
🔑 :key: when dealing with security
🔁 :repeat: when updating dependencies or data
:white_check_mark: when a new release was built
👕 :shirt: when refactoring or removing linter warnings
:x: when removing code or files

... and looks awesome in the commit history:

How much effort do you put into commit messages and could you share your own techniques to stay organized in the version tree?

Discussion (28)

pic
Editor guide
Collapse
pbnj profile image
Peter Benjamin

I follow the Conventional Commit standard, because it allows me to automate Semantic Versioning in CI pipelines.

Examples:

  • Added a new CLI command? $ git commit -m "feat: add foo command" && git push then CI tests, builds, and increments MINOR version 1.0.9 -> 1.1.0, and publishes artifacts.

  • Fixed a race condition bug? $ git commit -m "fix: fix race condition" && git push then CI tests, builds, and increments PATCH version 1.1.0 -> 1.1.1, and publishes artifacts.

  • If a feature or bug fix is non-backward compatible, then add BREAKING CHANGE in git commit message, which will lead to incrementing the MAJOR version 1.1.1 -> 2.0.

If any change needs some context (eg why the change was made), I add it in the commit message body. More often, I reference the ticket or issue in bug tracker, like:

$ git commit -F- <<EOF
fix: fix race condition

Closes #123
EOF
Enter fullscreen mode Exit fullscreen mode
Collapse
maddypie profile image
Adarsh TS

This looks interesting. I should look this up soon. Maybe I can reach out to you, if I need some help.

Collapse
jack profile image
Jack Williams

I like this, I'm curious, do you use something automated to handle your semantic versioning like this?

Collapse
pbnj profile image
Peter Benjamin

I use semantic-release for all my projects. I like it because it is language-agnostic.

  1. Add a .releaserc.json config file, which supports a large number of plugins.
  2. Run semantic-release CLI in CI.
Collapse
sagar profile image
Sagar

I'm using git alias for writing beautiful commit messages. Below, I pasted a few lines from the .gitconfig file.

# Git Commit, Add all and Push — in one step.
cap = "!f() { git commit -m \"$@\"; }; f"
# NEW.
new = "!f() { git cap \"📦 NEW($1): $2\"; }; f"
# IMPROVE.
imp = "!f() { git cap \"👌 IMPROVE($1): $2\"; }; f"
# UPDATE.
up = "!f() { git cap \"✍🏻 UPDATE($1): $2\"; }; f"
# FIX.
fix = "!f() { git cap \"🐞 FIX($1): $2\"; }; f"
# RELEASE.
rlz = "!f() { git cap \"🚀 RELEASE($1): $2\"; }; f"
# DOC.
doc = "!f() { git cap \"📖 DOC($1): $2\"; }; f"
# TEST.
tst = "!f() { git cap \"🤖 TEST($1): $2\"; }; f"
# BREAKING CHANGE.
brk = "!f() { git cap \"‼️ BREAKING CHANGES($1): $2\"; }; f"
# REMOVE
remove = "!f() { git cap \"🗑 REMOVE($1): $2\"; }; f"
# REFACTOR
ref = "!f() { git cap \"♻️ REFACTOR($1): $2\"; }; f"
# INITIAL COMMIT
int = "!f() { git cap \"🎉 INITIAL COMMIT($1): $2\"; }; f"
Enter fullscreen mode Exit fullscreen mode

Here is an example of an improvement commit.

git imp "scope" "actual commit message"
Enter fullscreen mode Exit fullscreen mode
Collapse
madza profile image
Madza Author

This is awesome 👍
Thanks for sharing 🙏❤

Collapse
eelstork profile image
Tea

There are conventions; without going semantic versioning all the way:

  • 50 chars max is considered good practice (yes that is extremely terse and I treat it as an ideal vs hard constraint)
  • A good commit fixes/adds one thing (and a good message concisely spells this out) imho bothering to detail commits beyond the terse one liner often signals an issue with the commit itself (not always)

In a team environment:

  • Except under duress/time pressure will not skimp on the extra time needed to write a concise, informative commit message.
  • Will definitely review commits more carefully if a concise, informative message is not provided (and likely to ask for an updated diff)

Own work: will stop and ask myself what's going on when I err on the "improved a thing" side of things for any length of time as this could signal I'm losing focus or trying to muddle through/conflating separate issues.

Collapse
mat_kovac profile image
Matej Kovac

When working in a team, I always use ticket number and description of a change, where change is always localized, not pushing 50 file changes in a single commit.
This allows me to go back to the ticket when looking at the code to see what were the exact requirements

Don't you just love seeing "WIP" and then 10+ file changed?

On a personal project, I always use some meaningful message, it just helps when looking at git blame and timeframes

Collapse
arashnrim profile image
Arash

I've honestly been one who has put in too much effort into Git commits (to the point where each commit had its own paragraph worth of a body message), but over the years I realised that being succinct is a better option to go.

I discovered Gitmoji some time this year, and I've been using it to help standardise and give a little more insight to what my Git commits do. Emojis are pictures, and pictures can be worth a thousand words sometimes!

Collapse
patarapolw profile image
Pacharapol Withayasakpunt

I recommend commitizen with cz-emoji.

Collapse
heroincommunity profile image
German Chyzhov

We are using strict git conventions at our project.
It includes branch naming like [feature|bugfix]/XXX-YYY-3-words-description, where XXX is a short name of project in Jira and YYY is a number of ticket.

For git commits we are using rules:
1) Name like XXX-YYY Do something
2) Name should be up to 80 symbols, detailed description if needed comes as new lines
3) Name should have imperative voice like "Do...", "Make...", "Fix..." instead of "Did","Making", "Fixes"

PR's should have the same naming conventions as git commits.

Collapse
madza profile image
Madza Author

Talking about being organized 💯👍

Collapse
yo profile image
Yo

Here are my examples!

$ git commit -am "Update icons in dark mode and Closes #256"
$ git commit -am "Add a new class to support mobile devices and Closes #259"
Enter fullscreen mode Exit fullscreen mode
Collapse
ravenblood7 profile image
Juan Jaques du Preez

Did you know a commit can be quite long actually? I usually have a short title like 'Ticket Number: short description' and then follow with details in a short paragraph.

It may be overkill but commits aren't for you. It's for the poor maintainer trying to add a new feature a year from now. It helps for them to know what the hell you were thinking when you made the change.

Collapse
gawonmi profile image
gawonmi

this

Collapse
patarapolw profile image
Pacharapol Withayasakpunt

git commit -m update

Seriously lazy sometimes.

Collapse
aleaallee profile image
Alejandro esquivel

Almost none, most of my commits are "add x functionality" or "fix x functionality".

Collapse
michelledev3 profile image
michelledev

I think I will remember and bam, 10 commits later--no idea. I have been getting better with specifics, but sometimes I fall back into bad habits. Nice article Madza!

Collapse
mizunno profile image
Mizunno

Good post! Seems pretty useful indeed. But I'd rather try to write better short messages and that is a hard skill to master I think...

Collapse
madza profile image
Madza Author

Thanks and glad you liked it 🙏❤

Collapse
vinicioslc profile image
Vinicios de Lima Clarindo

Keep calm and Commit lint

Collapse
jj profile image
Juan Julián Merelo Guervós

The answer is "probably not enough"

Collapse
maddypie profile image
Adarsh TS

Thank you for sharing this. It's looks fun and interesting to include Gitmoji's as a single shot summary. I should start following this in my future commits.

Collapse
carlosgallego98 profile image
Jean Carlos

Not much to be honest, maybe its because I work on a duo (sometimes) or completely alone, but the problem comes when the typo appears 🤣🤣

Collapse
jessekphillips profile image
Jesse Phillips

Quite a bit. But it is less about the message and more about the commit itself. I have too much to say on the subject.

Collapse
madza profile image
Madza Author

Thank you for sharing 🙏❤

Collapse
ljcdev profile image
ljc-dev

Interesting post thx for sharing 😀! I guess I'll start adding emoticons then ✨.

Collapse
sunmik profile image
Sunmi

Interesting!