DevOps Bootcamp · Lesson

Best Practices for Commit Messages

Adopt conventions for writing clear, concise, and informative commit messages that improve project history readability.

Best Practices for Commit Messages is a free DevOps Bootcamp lesson on CoddyKit — lesson 3 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the DevOps Bootcamp learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

Why Good Commits Matter

Imagine looking back at your project's history. Without clear commit messages, it's like reading a diary with blank entries!

Good commit messages are crucial for understanding why changes were made, what was changed, and how they impact the project. This helps you and your team debug, review code, and onboard new members.

Anatomy of a Commit Message

A standard Git commit message has two main parts:

Subject Line: A single, concise line summarizing the change.
Body (Optional): A more detailed explanation, separated from the subject by a blank line.

Think of it like an email: a subject line for quick scanning, and a body for details.

Crafting the Subject Line

The subject line is the most important part. Here are the rules:

Concise: Keep it under 50-72 characters.
Imperative Mood: Start with a verb in the present tense (e.g., "Add feature", not "Added feature" or "Adding feature").
Capitalize First Letter: Standard practice for readability.
No Period: Don't end the subject line with a period.

Subject Line Examples

Let's see some good and bad subject lines:

Good: Fix: broken login button
Good: Feat: implement user profile page
Bad: Fixed a bug in the login system that was causing issues. (Too long, past tense)
Bad: updates (Too vague)

Aim for clarity and brevity!

The Commit Body: Explain 'Why'

The commit body is where you explain the motivation for the change, the context, and any details that aren't obvious from the code itself.

Use it when your change needs more explanation than the subject line can provide. Keep lines wrapped around 72 characters for better readability in Git tools.

Body Content Guidelines

When writing the body:

Explain why the change was made, not just what.
Describe any trade-offs or design decisions.
Mention potential side effects or areas to watch.
Keep a blank line between the subject and the body.

This provides valuable context for future readers.

Full Commit Message Example

Here's how a full, well-structured commit message might look:

feat: add user authentication via email/password

This commit introduces a new user authentication system.
Users can now register with an email and password, and log in.

Key changes include:
- New /register and /login API endpoints.
- Integration with bcrypt for password hashing.
- JWT token generation for session management.

Closes #42

Using Type Prefixes (Conventional Commits)

Many teams adopt a convention where the subject line starts with a type prefix. This helps categorize changes quickly.

Common prefixes include:

feat: (new feature)
fix: (bug fix)
docs: (documentation change)
style: (code style, no functional change)
refactor: (code refactoring)
test: (adding tests)
chore: (maintenance, build process changes)

Referencing Issues & PRs

It's great practice to link your commits to related issues or pull requests in your project management system (e.g., GitHub Issues, Jira).

You can do this by including phrases like Closes #123, Fixes #45, or Refs #67 in your commit message, usually in the body. This automatically connects your code changes to the task being tracked.

Commit Message Check

Which of the following are characteristics of a well-written Git commit message, according to best practices?

Recap: Master Your Commits

You've learned that well-crafted commit messages are vital for project clarity and collaboration. By following these best practices, you make your project history a valuable resource!

Keep subject lines concise and in the imperative mood.
Use the body to explain 'why' a change was made.
Consider type prefixes for categorization.
Link to issues or pull requests for context.

Happy committing!

Frequently asked questions

Is the “Best Practices for Commit Messages” lesson free?

Yes — the full text of “Best Practices for Commit Messages” is free to read here on the web, and the DevOps Bootcamp course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the DevOps Bootcamp course, upgrade to CoddyKit PRO.

What will I learn in “Best Practices for Commit Messages”?

Adopt conventions for writing clear, concise, and informative commit messages that improve project history readability. You practise DevOps Bootcamp with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start DevOps Bootcamp?

No prior experience is required. DevOps Bootcamp on CoddyKit is structured for beginners through advanced learners; this is — lesson 3 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Best Practices for Commit Messages” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this DevOps Bootcamp lesson?

Yes. Every DevOps Bootcamp lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

← Back to DevOps Bootcamp