I’ll stick with
git commit . -m "stuff"/sCome on, just
"stuff"is way too vague…It’s either
"fixed stuff"for a 3k LoC commit where you moved a bunch of stuff around, or"Added stuff"for a 5k+ LoC commit if you actually added anything newAnd then
git ci -am "Addressed performance issue in flurbin module The flubin module was designed as a successor to the flurbar module which took in... [...500 line essay on the hostory, problem and solution deleted...] Hopefully this will fully fix the issue discussed."for a one character change that adds an additional, and unrequired, semicolon.
I just got started with this after seeing it on here a few weeks ago. And so far I really like it
For anyone using conventional commits I highly recommend adding Semantic Releases to your pipeline: https://github.com/semantic-release/semantic-release
I’m always scared when adding automation around manual inputs that people won’t follow the proper syntax and screw everything.
My previous job was to write official documents for engineering changes in an aerospace company, standardized English and everything. Even with the really strict guideline we had typos, self-inculpating wordage and the likes quite often.
Automation doesn’t have to be 100%. You can just use the generated change log as starting point and follow your usual process.
Automatically determining a semantic version bump (based on the types of commits landed).
That’s overly optimistic. It’ll be wrong the moment one person forgets one exclamation mark in one commit message. And it might not even be their fault if it’s not clear at the time it causes breaking changes somewhere downstream.
You can’t replace proper release engineering.
