A well-written commit message is essential for maintaining a clear and understandable project history. This page provides guidelines, examples, and best practices for writing effective commit messages.
- Improve Collaboration: Help team members understand the purpose of changes.
- Simplify Debugging: Provide context for troubleshooting and identifying issues.
- Enhance Documentation: Serve as a log of project evolution.
- Enable Automation: Facilitate release notes, changelogs, and versioning tools.
A typical commit message has two parts:
- Subject Line: A concise summary of the changes.
- Body (Optional): A detailed explanation of the changes, reasons, and any relevant context.
Add user authentication to the login page
- Implement password hashing using bcrypt.
- Add user login and logout functionality.
- Update tests to cover new authentication flows.
Fixes issue #42.
- Limit it to 50 characters or less.
- Summarize the change in a way that’s easy to understand.
Write the subject line as if giving a command:
- ✅ Add user authentication
- ❌ Added user authentication
- ❌ Adding user authentication
Explain:
- What changes were made.
- Why the changes were necessary.
- How they solve the problem.
Leave a blank line between the subject and the body to improve readability.
Mention related issue IDs or task numbers:
Fix login bug for admin users (#123)
Be precise and descriptive to ensure the message is clear.
Type | Description | Example |
---|---|---|
Feature | Introduces a new feature. | Add search functionality to the navbar |
Bug Fix | Fixes an issue or defect. | Fix crash on login page when email is null |
Refactor | Improves code without changing functionality. | Refactor user authentication module |
Docs | Updates documentation. | Add usage examples to the README |
Style | Changes formatting or code style. | Format code to match project style guide |
Chore | Miscellaneous tasks like dependency updates. | Update npm packages to latest versions |
Fix typo in error message
Add user profile page
- Create a new UserProfile component.
- Fetch and display user data from the API.
- Add tests for the UserProfile component.
Closes #98.
Refactor database connection logic
- Extract database connection into a separate module.
- Ensure all services use the shared connection module.
- Improve error handling during database initialization.
- Commit Often: Make small, logical commits instead of large, all-encompassing ones.
- Avoid WIP Commits: Avoid vague messages like
WIP
(Work in Progress) orFix stuff
. - Use Templates: Establish a standard commit message format for your team.
Set up a commit-msg
hook to validate commit messages:
#!/bin/bash
# Example commit-msg hook
MESSAGE=$(cat $1)
if ! [[ $MESSAGE =~ ^(Fix|Add|Refactor|Update|Remove|Docs): ]]; then
echo "Commit message must start with a valid type (e.g., Fix, Add, Refactor)."
exit 1
fi
- Conventional Commits: Standardizes commit messages for automation.
- Linting Tools: Use tools like commitlint to enforce rules.
Command | Description |
---|---|
git commit -m "message" |
Commit with a single-line message. |
git commit |
Open the default editor for writing a message. |
git commit --amend |
Edit the most recent commit message. |
Use the --amend
option:
git commit --amend
Yes, use Git hooks or tools like commitlint to validate messages.
Modify files in your working directory.
git add .
git commit -m "Add password hashing for user authentication"
Good commit messages are a cornerstone of effective collaboration and project maintenance. By following best practices and writing clear, concise messages, you ensure that your project history is understandable and useful to all contributors.
Next Steps: Maintaining a Clean History