# Commit Guidelines

When contributing to this project, please follow these commit guidelines to maintain a clear and organized version history.

## Commit Message Format

Each commit message should adhere to the following format:

```
<type>(<scope>): <message>
```

- **Type:** Describes the purpose of the commit (e.g., feat, fix, docs, style, refactor).
- **Scope:** Indicates the scope or module affected by the commit (optional).
- **Message:** Provides a concise and clear description of the changes.

### Examples:

- feat(user-auth): add user authentication feature
- fix(api): resolve issue with data retrieval
- doc(readme): update installation instructions
- test(adb): add basic mode adb test cases

## Commit Types

Choose the appropriate type for your commit:

- **feat:** A new feature for the user or a significant change.
- **fix:** A bug fix.
- **doc:** Documentation changes.
- **style:** Code style changes (e.g., formatting).
- **refactor:** Code refactor without adding new features or fixing bugs.
- **test:** Adding or modifying tests.
- **chore:** Routine tasks, maintenance, or tooling changes.

## Additional Guidelines

- Make each commit message concise and focused.
- Use present tense (e.g., "add feature" instead of "added feature").
- If your commit addresses an open issue, reference it in the message (e.g., "fix #123").
- Squash multiple related commits into a single, coherent commit before opening a pull request.

Thank you for following these guidelines and contributing to our project!
