5 ms·
Interesting, after years of software-development I arrived at almost the same pattern: * [feature] -> a new feature, can be incomplete, but should be a contain
by fn1 4y ago
Interesting, after years of software-development I arrived at almost the same pattern:
* [feature] -> a new feature, can be incomplete, but should be a contained unit of work that's usable to the enduser in some way.
* [code] -> everything that improves the code, could be refactoring, library-updates or preparations for a feature
* [bugfix] -> minimal commit only for fixing a bug, should (almost) always include a test to reproduce the bug.
Sometimes I also use:
* [build] -> for build-improvements
* [performance] -> for performance-improvements
- beanaroo 4y agoAfter working on a number of projects that tried to apply conventional commits properly, I found something like this to be more effective and sustainable. Specifically, I'm quite fond of https://gitmoji.dev https://gitmoji.dev - Commit messages are shorter, even with ticket IDs. - Commit log is easy to read - Less prone to typos (chroe vs chore) - Easy to enforce with push rules - Easy to generate changelogs/release notes - Easy to measure (metrics) - Helpful IDE integrations - It's a bit more fun than conventional commits See https://github.com/tiangolo/fastapi https://github.com/tiangolo/fastapi for an example