To that end you will want to provide a validating parser and then start rejecting commits whose messages don’t validate. If your validator has even one or two bugs you’re going to see all goodwill evaporate, and for what? So that you could read:
bug(fix)[8177] Add missing paren
instead of Add missing paren
…
Fixes http://bugs.com/8177
Commit messages are the primary source of why you did something. Focus all of your energy on writing clearly, concisely, and compellingly, and helping others to get better at doing so. Working on anything else is wasted energy compared to the importance of honing written communication skills.The example of using one library over another, especially if research has gone into which to choose, regularly involves say finding a good article that compares the alternatives.
I’ll say though that I usually include links to more notable references, I won’t usually commit refs to a libraries own docs and more obvious stuff; revealing and keeping references to resources found that went towards getting it done are what I keep and add to commit body.
Maybe there’s spaces for useful references to be added to the spec/conventions. Personally I usually show links like this after the body message.
Example of the commit body:
refs(oath-library):
www.something.com/picking-a-thing
This gives product owners the ability to embellish as they wish and reduces the need of the dev to repeat themselves.
Your 'intent' is 'users need social login'? That does not make sense.
Your intent is 'Getting more users by lowering barriers to sign up', a business goal. That business goal might have hierarchical children – for example, Jira epics – such as 'offer social sign-in', or 'declutter landing page.'
Also, the commit mentions 'Google before GitHub', but how can a commit (a snapshot of the repository) know the future? What if your product manager decides Google is fine enough and GitHub/Apple aren't needed?
I wish our profession would stop trying to reinvent issue tracking in git every week.
Agentic coding keeps reinventing coding.
That was my first thought.
> And then it hit me - the commit body has always been there. Completely underutilised.
Wait. What? This is the standard?
> Here is an example of how a Contextual Commit looks:
The format is key-value stuff. You can already use trailers for that. The syntax here doesn’t work with that stuff.
If you have already readh the “conventional commits” (pronounce with a sneer) specification you have already seen them. They’re called footers because they also didn’t know about trailers.
> No new tools. No infrastructure. Just better commits.
Okay, let’s cut right to the point..