git:commit

$27

• Verify before committing: Ensure code is linted, builds correctly, and documentation is updated

• Atomic commits: Each commit should contain related changes that serve a single purpose

• Split large changes: If changes touch multiple concerns, split them into separate commits

• Conventional commit format: Use the format <type>: <description> where type is one of:

• feat: A new feature

• fix: A bug fix

• docs: Documentation changes

• style: Code style changes (formatting, etc)

• refactor: Code changes that neither fix bugs nor add features

• perf: Performance improvements

• test: Adding or fixing tests

• chore: Changes to the build process, tools, etc.

• Present tense, imperative mood: Write commit messages as commands (e.g., "add feature" not "added feature")

• Concise first line: Keep the first line under 72 characters

• Emoji: Each commit type is paired with an appropriate emoji:

• ✨ feat: New feature

• 🐛 fix: Bug fix

• 📝 docs: Documentation

• 💄 style: Formatting/style

• ♻️ refactor: Code refactoring

• ⚡️ perf: Performance improvements

• ✅ test: Tests

• 🔧 chore: Tooling, configuration

• 🚀 ci: CI/CD improvements

• 🗑️ revert: Reverting changes

• 🧪 test: Add a failing test

• 🚨 fix: Fix compiler/linter warnings

• 🔒️ fix: Fix security issues

• 👥 chore: Add or update contributors

• 🚚 refactor: Move or rename resources

• 🏗️ refactor: Make architectural changes

• 🔀 chore: Merge branches

• 📦️ chore: Add or update compiled files or packages

• ➕ chore: Add a dependency

• ➖ chore: Remove a dependency

• 🌱 chore: Add or update seed files

• 🧑‍💻 chore: Improve developer experience

• 🧵 feat: Add or update code related to multithreading or concurrency

• 🔍️ feat: Improve SEO

• 🏷️ feat: Add or update types

• 💬 feat: Add or update text and literals

• 🌐 feat: Internationalization and localization

• 👔 feat: Add or update business logic

• 📱 feat: Work on responsive design

• 🚸 feat: Improve user experience / usability

• 🩹 fix: Simple fix for a non-critical issue

• 🥅 fix: Catch errors

• 👽️ fix: Update code due to external API changes

• 🔥 fix: Remove code or files

• 🎨 style: Improve structure/format of the code

• 🚑️ fix: Critical hotfix

• 🎉 chore: Begin a project

• 🔖 chore: Release/Version tags

• 🚧 wip: Work in progress

• 💚 fix: Fix CI build

• 📌 chore: Pin dependencies to specific versions

• 👷 ci: Add or update CI build system

• 📈 feat: Add or update analytics or tracking code

• ✏️ fix: Fix typos

• ⏪️ revert: Revert changes

• 📄 chore: Add or update license

• 💥 feat: Introduce breaking changes

• 🍱 assets: Add or update assets

• ♿️ feat: Improve accessibility

• 💡 docs: Add or update comments in source code

• 🗃️ db: Perform database related changes

• 🔊 feat: Add or update logs

• 🔇 fix: Remove logs

• 🤡 test: Mock things

• 🥚 feat: Add or update an easter egg

• 🙈 chore: Add or update .gitignore file

• 📸 test: Add or update snapshots

• ⚗️ experiment: Perform experiments

• 🚩 feat: Add, update, or remove feature flags

• 💫 ui: Add or update animations and transitions

• ⚰️ refactor: Remove dead code

• 🦺 feat: Add or update code related to validation

• ✈️ feat: Improve offline support

Guidelines for Splitting Commits

When analyzing the diff, consider splitting commits based on these criteria:

• Different concerns: Changes to unrelated parts of the codebase

• Different types of changes: Mixing features, fixes, refactoring, etc.

• File patterns: Changes to different types of files (e.g., source code vs documentation)

• Logical grouping: Changes that would be easier to understand or review separately

• Size: Very large changes that would be clearer if broken down

Examples

Good commit messages:

• ✨ feat: add user authentication system

• 🐛 fix: resolve memory leak in rendering process

• 📝 docs: update API documentation with new endpoints

• ♻️ refactor: simplify error handling logic in parser

• 🚨 fix: resolve linter warnings in component files

• 🧑‍💻 chore: improve developer tooling setup process

• 👔 feat: implement business logic for transaction validation

• 🩹 fix: address minor styling inconsistency in header

• 🚑️ fix: patch critical security vulnerability in auth flow

• 🎨 style: reorganize component structure for better readability

• 🔥 fix: remove deprecated legacy code

• 🦺 feat: add input validation for user registration form

• 💚 fix: resolve failing CI pipeline tests

• 📈 feat: implement analytics tracking for user engagement

• 🔒️ fix: strengthen authentication password requirements

• ♿️ feat: improve form accessibility for screen readers

Example of splitting commits:

• First commit: ✨ feat: add new solc version type definitions

• Second commit: 📝 docs: update documentation for new solc versions

• Third commit: 🔧 chore: update package.json dependencies

• Fourth commit: 🏷️ feat: add type definitions for new API endpoints

• Fifth commit: 🧵 feat: improve concurrency handling in worker threads

• Sixth commit: 🚨 fix: resolve linting issues in new code

• Seventh commit: ✅ test: add unit tests for new solc version features

• Eighth commit: 🔒️ fix: update dependencies with security vulnerabilities

Command Options

• --no-verify: Skip running the pre-commit checks (lint, build, generate:docs)

Branch Naming Convention

When committing on master or main, the command will ask if you want to create a new branch. If yes, it creates a branch following this pattern:

<type>/<git-username>/<description>

Components:

• <type>: The commit type (feature, fix, docs, refactor, perf, test, chore, etc.)

• <git-username>: Your git username (obtained from git config user.name or the system username)

• <description>: A kebab-case description of the change (e.g., add-user-auth, fix-login-bug)

Examples:

• feature/leovs09/add-new-command

• fix/johndoe/resolve-memory-leak

• docs/alice/update-api-docs

• refactor/bob/simplify-error-handling

• chore/charlie/update-dependencies

Workflow:

• Command detects you're on master or main

• Asks: "You're on the main branch. Do you want to create a separate branch?"

• If "No": Proceeds with commit on current branch

• If "Yes": Analyzes your changes to determine the type, asks for a brief description, creates the branch, and proceeds with commit

Important Notes

• By default, pre-commit checks (pnpm lint, pnpm build, pnpm generate:docs) will run to ensure code quality

• If these checks fail, you'll be asked if you want to proceed with the commit anyway or fix the issues first

• If specific files are already staged, the command will only commit those files

• If no files are staged, it will automatically stage all modified and new files

• The commit message will be constructed based on the changes detected

• Before committing, the command will review the diff to identify if multiple commits would be more appropriate

• If suggesting multiple commits, it will help you stage and commit the changes separately

• Always reviews the commit diff to ensure the message matches the changes