When working on a project together, Git is a crucial tool that help teams collaborate smoothly. One of the key features is commits, which act like snapshots of the project's progress.
However, do you know which one of my commit add a new feature? I'm sure you won't, including me...
The problem is I was naming the commit randomly without looking at the context which makes it harder for me to identify when I want to revert the changes.
To solve the problem, there is a useful linter named commitlint. It will prevent us from naming our commits randomly
// git commit
git commit -m "oops"
// it will trigger this error
// ❌ type must be one of [build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test] [type-enum]
and force us to name the commit properly.
git commit -m "fix: resolve the issue related to comma"
git commit -m "feat: add a feature named calculator"
It's very clear and easy to understand the context, right?
The following are all the types that commitlint suggests and provides including the example commit:
- build --> Changes that affect the build system or external dependencies
git commit -m "build: update npm dependency"
- ci --> Changes to our CI configuration files and scripts
git commit -m "ci: add circleci configuration file"
- docs --> Documentation only changes
git commit -m "docs: update readme with installation instructions"
- feat --> A new feature
git commit -m "feat: add user authentication feature"
- fix --> A bug fix
git commit -m "fix: resolve issue with incorrect data rendering"
- perf --> A code change that improves performance
git commit -m "perf: optimize database query for faster response times"
- refactor --> A code change that neither fixes a bug nor adds a feature
git commit -m "refactor: reorganize code structure for better readability"
- style --> Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
git commit -m "style: format code according to Prettier standards"
- test --> Adding missing tests or correcting existing tests
git commit -m "test: add unit tests for user authentication"
There are many features of commitlint that I can't mention one by one, as well as installation guide. To know the detail you can directly access https://github.com/conventional-changelog/commitlint.
Top comments (13)
That sounds nice, but don't get me wrong
Good amount of dev will want to push code and don't care, and above all, do not understand the importance of a well written commit message.
Most don't even know how to use git cli, again, don't care and don understand the importance of it.
Best way I've found to enforce decent commit messages was to have a semrel stage in our CI.
If messages are not compliant, there will be no builds. Hence, work is not finished.
It's not perfect, but after a few weeks devs will follow the guidelines.
Relying on a local tool for it is troubling down the road.
Eider way, this should prevent some hiccup or distraction of the dev as long he cares heheh
Yeah, there are many ways to keep devs disciplined, especially in a company.
That's a good idea, btw!
Oh~ there is a
perftag. I didn't know that. Thanks for sharing the good post!Nice, This was also my concern, that was why i created this CLI tool to do that in our projects: github.com/pshaddel/homebrew-conve...
That's good!
Thank You!
Interesting. But I'd find it more useful as a server-side pre-commit hook that rejected bad commits. Herding cats to get all the developers on the team to install this client side makes it impractical for me.
Yeah, to make
commitlintpowerful, you can use npmjs.com/package/husky.nice. thanks
Needs an option to require a gitmoji
I love me some gitmoji.
Is there anyway we can use this or any alternative linter with Gitlens in VSCode?
Yeah, there is. You can use it with husky to make it powerful