feat: Master Your Git Commit Messages 📝✅

Let's be honest for a second. We have all been guilty of writing a commit message like this:

git commit -m "fixed stuff"

Or the classic:

git commit -m "wip"

While this gets the code saved, it turns your project history into a mystery novel that no one wants to read. 🕵️‍♂️ When you (or your teammates) look back in six months, you won't have a clue what changed.

Enter Conventional Commits. 🌟

This is a standardized way of writing commit messages that makes your history readable, understandable, and even readable by machines (for auto-generating changelogs!). Let's break down the vocabulary you need to look like a total pro.

The "Big Two": Features and Fixes 🚀🐛

These will make up the majority of your commit history.

1. feat (Feature)

Use this when you introduce a new capability to your application. If the user can do something new, it's a feature.

• When to use: Adding a search bar, creating a new page, adding a button.
• Example:

  feat: add user login functionality

2. fix (Bug Fix)

Use this when you squash a bug. 🐛 It signifies a patch to existing code.

• When to use: Resolving a crash, fixing a typo, correcting a calculation error.
• Example:

  fix: correct typo in login error message

The "Housekeeping" Crew 🧹✨

These types keep your codebase clean, fast, and documented without changing the core business logic.

3. docs (Documentation)

Strictly for changes to documentation files. No code changes allowed here!

• Example:

  docs: update README with setup instructions

4. style (Code Style)

Wait! This isn't for CSS changes (that's usually a feat or fix). This is for code formatting-things that the compiler/interpreter ignores but humans care about.

• When to use: Missing semicolons, whitespace changes, formatting with Prettier.
• Example:

  style: reformat code with Prettier

5. refactor (Refactoring)

The MVP of clean code. This is for changing the code structure without changing its behavior.

• When to use: Renaming variables for clarity, splitting a large function into two smaller ones.
• Example:

  refactor: simplify authentication middleware

6. perf (Performance)

Use this when you make a change specifically to make the code run faster. 🏎️

• Example:

  perf: optimize image loading by using lazy loading

7. test (Testing)

For adding missing tests or correcting existing ones. A healthy codebase sees a lot of these!

• Example:

  test: add unit test for auth service

The "Behind the Scenes" Types ⚙️🤖

These affect how your app is built or deployed, but not the app itself.

8. build

Changes that affect the build system or external dependencies.

• Example:

  build: update to Webpack 5

9. ci (Continuous Integration)

Changes to your CI configuration files and scripts (GitHub Actions, Travis, Jenkins).

• Example:

  ci: add GitHub Action for running tests

10. chore

The catch-all bucket. Use this for boring tasks that don't fit anywhere else, like deleting old files or updating a .gitignore.

• Example:

  chore: remove unused packages

11. revert

Use this when you are undoing a previous commit.

• Example:

  revert: revert "feat: add user profile page"

🔧 Pro Tips for Power Users

✨ Use Scopes

Want to be even more specific? Add a scope in parentheses to tell people where the change happened.

feat(auth): add JWT token support
fix(cart): resolve rounding issue

🚨 Breaking Changes

If you make a change that crashes the app for people using the old version (like removing a function), add an exclamation mark ! after the type.

feat!: drop support for Node 12

The Cheat Sheet 📝

Here is a quick summary table to keep by your desk:

Start using these today, and your future self (and your team) will thank you! Happy coding! 💻🎉