The two hardest things about coding are deciding what to name methods and writing a good commit message. Today, we’re tackling the latter.

Picture this: you’ve spent hours working late into the night on a difficult piece of code. When you finally finish, you feel an overwhelming sense of triumph—and maybe a bit of frustration. Conveniently, your commit message offers the perfect outlet to vent. “Fixed this stupid bug that made me cry,” you type, feeling vindicated.

While it might feel good to let out some choice words, this strategy isn’t exactly professional. (Want to see how others handle this? Check out latenightcommits.com for some entertaining examples.)

So, what makes a good commit message? Well, it depends. Let’s explore two common strategies that can help you write commit messages that are both effective and professional.

---

1. Ticket-Based Commit Messages

In team environments, especially those using tools like Jira or Trello, commit messages often start with the ticket number. This approach allows developers to quickly reference the relevant ticket for more details, making the commit easier to understand during code reviews or future debugging.

Here’s an example:

DEV-123 Implemented subscription CRUD functionality for end users

This message provides:

• A clear link to the ticket (e.g., DEV-123), which often contains more detailed documentation.
• A high-level summary of what was done, helping future developers quickly understand the change.

Pro Tip: If your team integrates Git with your ticket tracking system, you can use webhooks to turn these ticket numbers into clickable links. This makes it even easier to navigate between commits and tickets.

---

2. Conventional Commits

The Conventional Commits specification offers a structured way to write commit messages. This format is especially useful for projects that rely on automated tools for versioning or changelogs.

A Conventional Commit message typically includes:

• A type: Specifies the kind of change (e.g., feat for new features, fix for bug fixes).
• A brief description: Limited to 50 characters, summarizing the work done.
• A body (optional): A detailed explanation of the change, wrapped at 72 characters per line.
• Footers (optional): Additional metadata, like ticket numbers or reviewers.

Here’s an example:

feat(subscription): add subscription CRUD functionality for end users

Added create, read, update, and delete operations to manage user
subscriptions. This feature allows admins to handle subscriptionsmore efficiently.

JIRA-123

For full documentation on this approach, check out conventionalcommits.org.

---

Practice Makes Perfect

Commit messages can be harder to write than they seem. Like naming methods, it’s a skill that improves with practice.

If you’re working solo, you might get away with silly or frustrated commits. But in a team environment, following conventions—whether ticket-based or structured like Conventional Commits—makes the project easier to maintain and benefits everyone.

Remember, a well-written commit message doesn’t just document your work; it communicates your thought process to your future self and your team. And that’s a gift that keeps on giving.

Happy Coding!