# Standard naming convention for commit messages

The standard naming convention for commit messages often follows the **Conventional Commits** specification. It helps to keep commit messages consistent and readable, especially when generating changelogs or tracking changes in a project.

Here are the common **types** of commit messages used in the **Conventional Commits** convention:

1. **feat**: A new feature or functionality.
    
    * Example: `feat: add user authentication flow`
        
2. **fix**: A bug fix.
    
    * Example: `fix: correct header alignment issue on mobile`
        
3. **docs**: Changes to documentation.
    
    * Example: `docs: update README with installation instructions`
        
4. **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.).
    
    * Example: `style: format code using prettier`
        
5. **refactor**: Code change that neither fixes a bug nor adds a feature (e.g., code cleanup or restructuring).
    
    * Example: `refactor: restructure user service logic`
        
6. **perf**: Changes that improve performance.
    
    * Example: `perf: improve database query performance`
        
7. **test**: Adding or updating tests.
    
    * Example: `test: add unit tests for login component`
        
8. **chore**: Changes to the build process, tooling, or other non-functional updates (e.g., package updates).
    
    * Example: `chore: update dependencies`
        
9. **build**: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm).
    
    * Example: `build: configure Webpack for production`
        
10. **ci**: Changes to Continuous Integration (CI) configuration files and scripts.
    

* Example: `ci: add Travis CI configuration`
    

11. **revert**: Revert a previous commit.
    

* Example: `revert: revert commit 12345abc`
    

12. **fix!** or **feat!**: Breaking changes in a fix or feature. The `!` indicates a breaking change.
    

* Example: `feat!: drop support for Node.js 8`
    

13. **merge**: For merging branches, though less commonly used if the merge commits are automatically created by Git.
    

* Example: `merge: merge feature branch into main`
    

### Structure of Commit Message:

```typescript
<type>(<scope>): <short summary>
```

* **Type**: What type of change it is (e.g., `feat`, `fix`, `docs`).
    
* **Scope**: A module or file the commit is related to (optional, but can be useful for large projects).
    
* **Short Summary**: Brief description of what was done (in imperative mood, e.g., "add feature", "fix bug").
    

### Example Commit Messages:

* `feat(authentication): add JWT-based user authentication`
    
* `fix(user-profile): resolve issue with profile picture upload`
    
* `docs(api): update API usage documentation`
    
* `refactor(utils): clean up redundant helper functions`
    

This style helps maintain clean and clear commit history, making it easier for teams to understand what each commit achieves.