The other day I was poking around in a github repository and came across this commit message:
Not that I needed to know that much about what thi...
For further actions, you may consider blocking this person and/or reporting abuse
I wrote a tool called golem, something similar inspired by commitizen. I made it in Go, so that I could compile it into a single binary and be able to recommend it to my fellow developers who don't use nodejs.
github.com/geocine/golem
The JIRA ID is optional, can also remove the option totally on the source code.
I like this a lot - one suggestion, rename "JIRA issue(s) ID" to something more generic like "Issue(s) ID" to make it adaptable to other issue trackers (eg Github)
Great post! I absolutely love the movement of making commit messages better! 😁 Don't forget to mention that the format Commitizen is using is based on Conventional Commits 😁There are also a lot of tools to do awesome stuff with these commits, like generating changelogs (example of one of my projects) or even "calculate" next semantic version (also example a project of mine).
Here are some of them!
Disclaimer; I became one of the maintainers of Commitlint and we joined the Conventional Changelog "group" on GitHub. That basically makes me a CC fanboy I guess 😅
Awesome! I'll have to check these out. We use some linting on our commit messages as well and I think its great. Also, I've updated the post to mention Conventional commits 😄
Haha nice! Hope most of the developers there are like you and think it's great too 😁 I had to convince some of our developers to stop make "annoyed sounds" and embrace the new standards 😅 Again, awesome article!
I personally use gitmoji-cli for my commits: github.com/carloscuesta/gitmoji-cli
It uses emojis to define the type of commit and makes your repo a lot more colourful
Example of a repo using it: github.com/RigsOfRods/rigs-of-rods
This is very fun 🐛
One particular commit format I've found which works really well in creating commits with intent is the following:
An example toy commit message would read like this:
Tip: Don't create commits like this initially. Commit frequently on your local feature branch as your fancy strikes, and don't be afraid to write minimal descriptions on your messages. However, when the time comes to push your commits up to your main shared branch, rebase your feature commits into one, and write a commit message like this one.
This is a good template for pull requests, but personally I don't recommend squishing pull requests into one commit.
May I know why you recommend not squashing commits for smaller PRs? I can see it shouldn't be done for larger PRs, but for simpler single-feature stuff (which you'd get anyway on frequent integration) setting a single commit would work well. You'd have a relatively cleaner git history and quick reverts if needed as well.
I find it better to have more commits for
git-bisect.Then it ends up being a specific incorrect refactor, which can be made an example of, by adding regression tests, mentioning it in team guidelines, adding lints etc.
When you want to revert the whole merge, you can still use a UI button or
git revert -m 1 <merge-commit>.As for full diffs, it's just as easy to diff two arbitrary points as the state before and after a single commit.
I just don't think it brings anything useful to the table.
Maybe it's appropriate to squash-merge to the
release(notmaster) branch in a non-CD situation. Not sure.A trick I use for even better commit messages is card numbers (something I always do when I have the choice is number my cards in the backlog). I'll write my commit messages like this:
Card #15 - Fixed issue with string concatenation showing null, ShipState set to blank if null before customer is created.
I've found that card numbers allows you to add more robustness to your commit message without being overly wordy. If you REALLY need to research the changes that went on, you have a card number, so you can go reference that for the (hopefully) full breakdown and steps that went into the card.
One might say you're suggesting one really commit to their commits ;)!
Ok, now that the pins out of the way: thanks for sharing this! My team is currently in the process of reworking how we handle our source control and everyone is pretty new to it... the ideas here, in addition to the tool itself, are very helpful to read.
Hi All,
Thanks for this great article Erin!
Good to see this conversation picking up around quality commit messages because my experience is that it's not the favorite topic of developers. At least it's pretty dividing whenever I bring it up. Usually, folks working at a large company in a regulated industry (aviation, healthcare, finance, etc) get it, because they need to comply with a buch of rules.
We work on a Jira app that checks and verifies several aspects of a commit not only at push time but right on your computer at local commit time.
I talked to a developer at Philips whose team is using it. If you are using Jira and interested give this quick interview a read I made with them.
Thx for this! This is really what I wanted. Helped A LOT.
Can I translate in Korean this post? If you don't mind, I wanna share this awesome post in Korean. Surely, There will be a linke directing to this original post.
Thank you for making me discover whatthecommit.com!!!
Possibly NSFW text..? But this site always gives me a laugh for crazy things people put into commit messages: commitlogsfromlastnight.com/