Update build file
Fixes dependency array
Refactor
Fix tests
The most famous: Update README.md (Thanks Github 🤦)
These are... some spectacularly...
For further actions, you may consider blocking this person and/or reporting abuse
Communication is key, right?
Communiction for the future you or anyone else <3
haha yep!!
Thanks for writing this. A good commit history helps paint a better picture for a newcomer to the team. The quicker we can onboard understanding, the sooner we can realize our return on investment in hiring. Not to mention how much easier it is for existing team members (or ourselves) to rapidly understand what we meant when taking a later look at a project's code long after implementation.
Tbh, never read commit history unless to RCA. But interesting approach for sure.
Great article! Commits are you best friend while navigating a new code base :)
Nice looking releaseNotes is the most visible and satisfying reward.
Also, when an incident or something strange appears in production, reveiwing commit messages can be so precisous ;-p
new: ...
change: ...
remove: ...
People like to complicate things unnecessarily.
Oh yeah. Devs have a tendency to over-engineer things, don't we? 😄
But I'd say the new/change/remove structure might prove insufficient.
To me, a commit message should just combine these 3 into a small description of the change, and a few words (or a ticket/issue ref) about why.
But again, I don't expect someone to realistically do this for every single commit ever. Only for the more consequential commits. A commit that removes a stray console.log can just say "Removes stray log".
Loved the cameo of Sheldon in the article 😂
Sad to say it wasn't even my idea to add it in there.
nice read. I always use commitzen to commit.
Ever heard of "Conventional Commits"?
Oh yeah, absolutely!
I should have mentioned that in the post, truly.
Conventional commits are awesome, but they can be overwhelming for devs who don't understand the need for them in the first place.
Because I often find conventional commits to be a little too opinionated and rigid for new devs, or devs who are just getting to understand the need for good commit messages.
I'd say conventional commits is the next step one can take after they understand why a good commit message helps, but again, not everyone needs something as thorough of a spec as conventional commits. It depends on your needs and troubles (like most things, isn't it?)
I'll add this to the post though. Thanks for the reminder!
Added it. Good stuff!
Btw, in case you didn't yet, maybe aicommit.app/ will be interesting to you!
This is interesting, thanks.
I find it quite difficult to use the git extension on Vs Code. How can I format my commit message in the terminal the way it was cited in this article?
You can change your git commit editor to use nano, or vim for a relatively convenient experience.
I personally just use the continuation character (\) to add multiline commit messages. Let me know if an example will help.
In the cli each
-moption to git commit add a new line containing the associated text argument.That's new to me! Thanks for sharing @tetedacier!
Looking forward to gpt-generated commit from
git statussummaries of commit batches...Maybe you can look into aicommit.app/
Very good article! :)
Thanks, Luma!