Git Commit Guide
Use Conventional Commits to write consistent and meaningful commit messages. This makes your work easier to review, track, and maintain for everyone involved in the project.
✍️ Commit Message Format
<type>(<scope>): <description>
<body>
<footer(s)>
Components:
<type>: The type of change being made (e.g., feat, fix, docs).<scope>(optional): The scope indicates the area of the codebase affected by the change (e.g., auth, ui).<description>: Short description of the change (50 characters or less)<body>(optional): Explain what changed and why, include context if helpful.<footer(s)>(optional): Include issue references, breaking changes, etc.
Examples
Basic:
feat: add QR code scanner
With scope:
feat(auth): add login functionality
With body and issue reference:
fix(api): handle null response from login endpoint
Checks for missing tokens to prevent app crash during login.
Fixes #123
🏷️ Commit Types
| Type | Use for… | Example |
|---|---|---|
feat | New features | feat(camera): add zoom support |
fix | Bug fixes | fix(auth): handle empty username crash |
docs | Documentation only | docs(readme): update setup instructions |
style | Code style (no logic changes) | style: reformat settings screen |
refactor | Code changes (no features/fixes) | refactor(nav): simplify stack setup |
test | Adding/editing tests | test(api): add unit test for login |
chore | Tooling, CI, dependencies | chore(ci): update GitHub Actions config |
revert | Reverting previous commits | revert: remove feature flag |
📍Optional Scope
The scope is optional but recommended for clarity, especially for large changes or or when multiple areas of the codebase are involved.
| Scope | Use for… | Example |
|---|---|---|
auth | Authentication | feat(auth): add login functionality |
settings | User settings | feat(settings): add dark mode toggle |
build | Build system | fix(build): improve build performance |
ui | UI/theme | refactor(ui): split theme into modules |
deps | Dependencies | chore(deps): bump Kotlin to 2.0.0 |
🧠 Best Practices
1. One Commit, One Purpose
- ✅ Each commit should represent a single logical change or addition to the codebase.
- ❌ Don’t mix unrelated changes together (e.g., fixing a bug and updating docs, or changing a style and ) adding a feature).
2. Keep It Manageable
- ✅ Break up large changes into smaller, more manageable commits.
- ✅ If a commit changes more than 200 lines of code, consider breaking it up.
- ❌ Avoid massive, hard-to-review commits.
3. Keep It Working
- ✅ Each commit should leave the codebase in a buildable and testable state.
- ❌ Never commit broken code or failing tests.
4. Think About Reviewers (and Future You)
- ✅ Write messages for your teammates and future self, assuming they have no context.
- ✅ Explain non-obvious changes or decisions in the message body.
- ✅ Consider the commit as a documentation tool.
- ❌ Avoid jargon, acronyms, or vague messages like
update stuff.
Summary
- Use Conventional Commits for consistency.
- Keep commit messages short, structured, and focused.
- Make each commit purposeful and self-contained.
- Write commits that make collaboration and future development easier for everyone—including you.