The Commit Message That Got Me Noticed by My Tech Lead

DevGlish Team

For two years, my git log looked like this:

I'm not proud of it. But at the time, commit messages felt like overhead. I knew what I'd changed — it was right there in the diff. Why spend time describing it in English when I could be writing the next feature?

The attitude changed when my tech lead pulled me aside after a sprint retrospective. She said, "Your code quality is great, but when I look at the git log to understand what happened this sprint, your commits are a black box. I have to open every diff to figure out what changed."

She wasn't criticizing my English. She was telling me that commit messages are part of the work, not decoration on top of it. A commit without a meaningful message is like a function without a name — it works, but nobody else can use it efficiently.

The commit message that changed things

That week, I had to fix a tricky race condition in our job queue. Two workers were occasionally processing the same job because the lock acquisition wasn't atomic. After debugging for most of an afternoon, I had a one-line fix — changing a SELECT followed by an UPDATE to a single UPDATE ... WHERE with a row-level lock.

Old me would have written: fixed race condition.

Instead, I spent five minutes writing this:

fix: prevent duplicate job processing with atomic lock acquisition

Workers could process the same job simultaneously because the
lock check (SELECT) and lock acquisition (UPDATE) were separate
statements. Between the SELECT and UPDATE, another worker could
read the same unlocked row.

Replace the two-step check-then-lock with a single UPDATE...WHERE
that atomically finds and locks an unprocessed job. This eliminates
the race window entirely.

Fixes #287

The next morning, my tech lead left a comment on the PR: "This is an excellent commit message. The problem description alone would have saved me hours if I'd been debugging this." She shared it in our team channel as an example of good documentation.

It was the first time my writing — not my code — had gotten a positive comment at work.

What I learned about the structure

After that, I studied commit message conventions obsessively. I read the Angular commit convention, Conventional Commits spec, and the git logs of popular open-source projects. Here's what I distilled:

The subject line is a command. Write "Add pagination to user list," not "Added pagination" or "Adding pagination." Use the imperative mood — as if you're telling the codebase what to do. This was counterintuitive to me because in normal English writing, you describe what you did (past tense). But in commit messages, the convention is imperative.

The subject line should be under 50 characters. This forces you to be precise. "Fix bug" is short but useless. "Fix race condition in job queue lock" is short and informative. The constraint is a feature — it prevents you from writing paragraphs in the subject line.

The body explains why, not what. The diff shows what changed. The commit message should explain why it changed. What was the problem? Why was this the right solution? Are there alternatives you considered and rejected? This is the part that helps future developers (including future you) understand the reasoning.

Reference issues. "Fixes #287" links the commit to the issue tracker. Six months later, when someone is investigating a regression, they can trace the commit back to the original bug report and all its context.

The English-specific challenges

Writing good commit messages in English had some challenges beyond the general conventions:

Imperative mood was confusing. In Hindi and in Indian English, we often use the continuous or past tense to describe completed actions. "I am fixing the bug" or "Fixed the bug" felt more natural than "Fix the bug." The imperative mood ("Fix," "Add," "Remove") sounds like you're giving an order, which felt strange for describing your own work. I had to train myself to think of it as instructions to the codebase.

Articles (a, an, the) were tricky. Hindi doesn't have articles, so I'd often drop them: "Fix race condition" instead of "Fix race condition in queue" or "Fix the race condition." In commit subject lines, dropping articles is actually acceptable and even preferred for brevity — so this worked in my favor. But in commit bodies, missing articles made the text feel telegraphic.

Precision required specific vocabulary. I needed to distinguish between "fix" (correct a bug), "refactor" (restructure without changing behavior), "update" (modify existing functionality), and "add" (introduce something new). In casual English, these words overlap. In commit messages, they have distinct meanings that reviewers rely on. DevGlish helped me nail down these distinctions by showing how each word is used in developer contexts specifically.

Templates that saved me time

I developed a set of mental templates that made writing commit messages faster:

For bug fixes: fix: [what was broken] by [how you fixed it]
Example: "fix: prevent timeout on large file uploads by streaming in chunks"

For features: feat: add [what] to [where]
Example: "feat: add dark mode toggle to settings page"

For refactors: refactor: extract [what] into [where/what]
Example: "refactor: extract validation logic into shared middleware"

For performance: perf: [what improved] by [how]
Example: "perf: reduce dashboard load time by lazy-loading charts"

These templates gave me a starting structure when I sat down to write a commit message. I didn't follow them rigidly, but they prevented the blank-page problem where I'd stare at the terminal not knowing what to type.

The ripple effects

Good commit messages improved more than my git log. They made me think more carefully about what each commit contained. If I couldn't summarize a commit in one subject line, it probably contained too many unrelated changes. This naturally led me to make smaller, more focused commits — which made code review easier, bisecting faster, and reverting safer.

My tech lead started assigning me to review other people's PRs more often. She told me it was because I "clearly thought about code changes at a level beyond just making things work." I'm pretty sure that perception came directly from the commit messages, not from any sudden improvement in my technical skills.

The lesson: how you communicate about your code matters almost as much as the code itself. A brilliant fix with a commit message that says "fix" is invisible. The same fix with a clear, descriptive message is a contribution to the team's collective understanding. It's worth the extra five minutes.

Related Articles