How to git commit

git commit

As a developer, writing commit messages is a crucial part of my workflow. However, I’ve recently become disappointed with those chatgpt-based commit message tools I’ve tried, including CLI tools and VSC plugins. They just aren’t good enough at the moment and not cheap enough for me to ignore the cost either. So, I’ve decided to reconstruct my personal habits of writing commit messages, which didn’t exist before.

After reading a couple of bloggers' posts online, I’ve come up with my own set of commit message standards.

[INITIAL] # Used for initial commits
[ADD] # Newly added features / components
[UPDATE] # Used for updated existing features
[REFACTOR] # Used when restructured existing codes, usually for better performance
[FIX] # Used to denote fixes
[TESTS] # For tests
[STYLES] # Commits regarding styles
[DOCS] # Documents related i.e. README
[REVERT] # When commit was reverted back to previous code
[PRODUCTION] # Production related commits
[WIP] # Used to denote Work In Progress for commits that are not final
[BUILD] # During the build process
[REMOVE] # Removing files or old, unnecessary code

To ensure consistency in my commit messages, I’ve also established a set of formatting rules:

For example:

[UPDATE, TESTS] update function abc

- [abc.js] update function abc
- [abc-test.js] update test for function abc

While it may seem like a tedious task, I actually start to enjoy writing commit messages myself. It gives me a chance to review and think about the progress I’ve made and the changes I’ve implemented. Such a great opportunity to take a step back and consider the bigger picture of the project. Automation may be able to do it for me, but it’s not the same as me taking the time to defacto doing it.