feat: Adding a New Feature
Learn how to write a Conventional Commits message for a new feature using the feat type. Covers the correct format, description guidelines, and when to use feat vs other types.
Detailed Explanation
The feat Commit Type
The feat type is used when you introduce a new feature or capability to your project. In Semantic Versioning terms, a feat commit triggers a minor version bump (e.g., 1.2.0 to 1.3.0), signaling to consumers that new functionality has been added without breaking existing behavior.
Example Message
feat: add user authentication with OAuth 2.0
When to Use feat
Use feat when your commit:
- Adds a new API endpoint, route, or page
- Introduces a new UI component or screen
- Implements a new CLI command or option
- Adds a new configuration option that enables new behavior
- Creates a new module or service
When NOT to Use feat
Do not use feat when you are:
- Modifying an existing feature without changing its public interface (
refactor) - Fixing a bug in an existing feature (
fix) - Improving performance of existing code (
perf) - Adding tests for existing code (
test)
Description Best Practices
Your short description should:
- Start with a lowercase verb in imperative mood ("add", not "added" or "adds")
- Stay under 50 characters
- Not end with a period
- Describe what the commit does, not how
With Optional Body
For complex features, add a body to explain the motivation:
feat: add user authentication with OAuth 2.0
Implement Google and GitHub OAuth providers using Passport.js.
Users can now sign in without creating a password. Session
tokens are stored in HTTP-only cookies with a 7-day expiry.
Use Case
You have just finished implementing a new search feature in your application. The search supports full-text queries with filters and pagination. You need a commit message that clearly communicates the addition to your team and allows automated tools to generate the correct changelog entry and version bump.