A specification for adding human and machine readable meaning to commit messages
conventionalcommits.org
A specification for adding human and machine readable meaning to commit messages
1–10 of 49 posts
Re: A specification for adding human and machine readable meaning to commit messages
#2I thought this was interesting, anyone using this? Is the juice worth the squeeze?
Full title: Conventional Commits A specification for adding human and machine readable meaning to commit messages
Re: A specification for adding human and machine readable meaning to commit messages
#3A coworker started a personal project & has- at least after a day or so of wild hacking- nice clean commits pretty close to this. I havent yet asked or found out what they're doing but looks great.
Recently I'be started using "subsystem: change" type. Knowing the area seems like the most important starting queue.
Re: A specification for adding human and machine readable meaning to commit messages
#4I thought this was interesting, anyone using this? Is the juice worth the squeeze? Full title: Conventional Commits A specification for adding human and machine readable meaning to commit messages
I do. I've got a plugin to help with remembering to do it and formatting - https://plugins.jetbrains.com/plugin/13389-conventional-comm...
The thing that it really helps doing (when you're using it) is avoiding doing multiple things in one commit. Features and refactors and fixes belong in different commits.
With this I can also look at my git log and quickly see on the places where I changed things (rather than style or refactor or docs or tests). This commit, with a few lines did this - not "this change was part of this much bigger commit."
Re: A specification for adding human and machine readable meaning to commit messages
#5The examples given are more "what" changed than "why" it was changed. These are low-value commit messages because they are redundant with the content of the commit itself.
It is almost like signing all your commits with your name or the current date. (Yes, I had a coworker who did this.)
Better commit messages tell you what the situation was around the commit: Ticket number, or who wanted the change, or any other context that might tell you why the code was changed the way it was.
Consider the dev accessing your commit through "blame". What does that user need to hear? Not which file or subsystem was changed. But the reason there is a change in the first place.
My habit has been to prepare longer commit messages, a paragraph or two of explanatory text for that future developer, who is most likely future me.
Policy at my company now squashes all my carefully-prepared commit messages into the one-liner "Merged $BRANCHNAME into main". I will probably just switch to the three character commit message "WIP" like my coworkers have done.
Re: A specification for adding human and machine readable meaning to commit messages
#6I thought this was interesting, anyone using this? Is the juice worth the squeeze? Full title: Conventional Commits A specification for adding human and machine readable meaning to commit messages
I follow it pretty closely. I don’t have any automation setup for changelogs or anything at this point, but it’s pretty easy for me, as back in ye old SVN/Trac days there were similar FIX, etc. semantics.
I often have trouble with enough room to have a meaningful subject but the time I include commit scope and Jira ticket number, but I don’t mind, I normally use the body anyway.
Re: A specification for adding human and machine readable meaning to commit messages
#7The examples given are more "what" changed than "why" it was changed. These are low-value commit messages because they are redundant with the content of the commit itself. It is almost like signing all your commits with your name or the current date. (Yes, I had a coworker who did this.) Better commit messages tell you what the situation was around the commit: Ticket number, or who wanted the change, or any other con…
all of that sounds awful, I'm sorry for your experiences.
many repos are successfully using conventional commits in a way that's not low value, clear and concise in message, and useful in blame and walking history.
Re: A specification for adding human and machine readable meaning to commit messages
#8I thought this was interesting, anyone using this? Is the juice worth the squeeze? Full title: Conventional Commits A specification for adding human and machine readable meaning to commit messages
many popular javascript open source projects leverage this; webpack, vite, etc. It's very compatible with semver.
all of my personal repos use it and any professional repos I have a say in use it.
Re: A specification for adding human and machine readable meaning to commit messages
#9The examples given are more "what" changed than "why" it was changed. These are low-value commit messages because they are redundant with the content of the commit itself. It is almost like signing all your commits with your name or the current date. (Yes, I had a coworker who did this.) Better commit messages tell you what the situation was around the commit: Ticket number, or who wanted the change, or any other con…
I've hit a couple shops in a row now where squashes are The Way. It's such a short-sighted and misguided policy.
I don't understand what is so appealing about a linear commit history. It's a fabrication of reality, and I have never been grateful for it, only enraged.
Why wouldn't you want to know what _actually_ happened? What is being gained besides an aesthetically pleasing "commits" tab on GitHub?
Re: A specification for adding human and machine readable meaning to commit messages
#10I thought this was interesting, anyone using this? Is the juice worth the squeeze? Full title: Conventional Commits A specification for adding human and machine readable meaning to commit messages
I do. I've got a plugin to help with remembering to do it and formatting - https://plugins.jetbrains.com/plugin/13389-conventional-comm... The thing that it really helps doing (when you're using it) is avoiding doing multiple things in one commit. Features and refactors and fixes belong in different commits. With this I can also look at my git log and quickly see on the places where I changed things (rather than styl…
Thanks for this tip about the plugin; I went looking and there is also an extension for vscode: https://marketplace.visualstudio.com/items?itemName=vivaxy.v...
Haven't tried it but I will.