📦 Commit Message Convention - beatriznonato/rede-do-bem GitHub Wiki

This project follows a standardized commit message convention to ensure consistency and improve collaboration.
We use commitlint along with simple-git-hooks to automatically validate commit messages.

• 📚 Keep the Git history clean and easy to read
• 🤖 Enable automation, like changelog generation and semantic versioning
• 👥 Improve collaboration and code review by using consistent language
• 🚨 Prevent poorly written or unclear commit messages

We use commitlint to enforce the Conventional Commits specification and simple-git-hooks to trigger validation automatically on every commit.

npm install --save-dev @commitlint/{config-conventional,cli} simple-git-hooks

In the root of your project, create a file named commitlint.config.js with the following content:

module.exports = { extends: ['@commitlint/config-conventional'] };

"simple-git-hooks": {
  "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
}

npx simple-git-hooks install

After setup, every time you make a commit, commitlint checks if your message follows the proper format.
If not, the commit will be blocked until the message is fixed ✅

A valid commit message follows this structure:

<type>: <short description>

Example:

feat: add user settings form validation

Common types include:

• feat – A new feature
• fix – A bug fix
• docs – Documentation only changes
• style – Changes that do not affect the meaning of the code (formatting, etc.)
• refactor – A code change that neither fixes a bug nor adds a feature
• test – Adding or correcting tests
• chore – Other changes that don’t modify src or test files

For more details, check out Conventional Commits.