Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
Resources
Rules
Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.
I'll stick with git commit . -m "stuff" /s
Come 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 new
And 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.