Developer English guide
Git Commit Messages and Code Review Comments in English
July 27, 2026
Writing a good commit message is a communication skill, not just a syntax rule. This guide covers the conventions that make commits readable, code review comments that are clear and professional, and the phrases that keep feedback constructive even when a change is required.
Commit message conventions
The imperative mood, the 50-character subject line, and the most common type prefixes. Each prefix is shown with a weak example and a stronger version.
Use the imperative mood
Git commit messages use the imperative mood: the subject line reads as if you are giving an instruction. Think of it as completing the sentence 'If applied, this commit will...'
“Added dark mode toggle”
“Adding dark mode toggle”
“Add dark mode toggle”
Keep the subject under 50 characters
GitHub truncates subject lines beyond 72 characters. 50 is the practical target because it fits in most UIs without wrapping. If you cannot summarize the change in 50 characters, the commit is probably doing too much.
feat:
A new feature visible to the user or API consumer. This is the most important prefix — it marks work that adds value.
feat: stuff
feat: add dark mode toggle to user settings
fix:
A bug fix. State what was broken, not just that something was fixed. The reader wants to know what behavior changed.
fix: bug fix
fix: prevent login redirect loop when session expires mid-request
docs:
Documentation changes only — README, inline comments, API docs. No production code changed.
docs: update readme
docs: add setup instructions for M1 Mac local environment
chore:
Maintenance tasks that do not affect the app behavior: dependency updates, build config, CI changes.
chore: update things
chore: upgrade eslint to v9 and fix resulting lint warnings
refactor:
Code restructuring with no behavior change. The tests still pass. The output is the same — only the internal structure improved.
refactor: clean up
refactor: extract email validation into a standalone utility function
test:
Adding or updating tests. No production code changed. A good prefix to use when improving coverage after a bug report.
test: add tests
test: add edge cases for token refresh handler — expired and malformed tokens
When to write a commit body
The subject line is not always enough. Here is when and how to write the body.
The commit body
Add a body when the why is not obvious from the subject line. Leave a blank line between the subject and the body. Wrap lines at 72 characters. Explain what changed and why, not how — the diff shows the how.
feat: add rate limiting to the login endpoint Without rate limiting, an attacker can try thousands of passwords per second against any account. This adds a 5-request-per-minute limit using the existing Redis cache. Refs: #412
Code review labels: nit, required, LGTM, and more
The labels that reviewers use to classify their comments. Knowing them saves you from treating every comment as a blocker.
nit:
Non-blockingShort for 'nitpick'. A tiny style or wording issue — not wrong, just a personal preference. The author can ignore it without blocking the merge.
“nit: this variable name could be `userCount` to match the rest of the file.”
suggestion:
Non-blockingA concrete improvement the reviewer thinks would make the code better. Take it or leave it — not required before merging.
“suggestion: you could extract this logic into a helper function to avoid repeating it in the next section.”
question:
Non-blockingGenuine curiosity, not criticism. The reviewer wants to understand a decision, not challenge it. It should feel safe to answer either way.
“question: why do we use a Map here instead of a plain object? Is there a performance reason?”
required: / blocker:
BlockingThis must be fixed before the PR can merge. A bug, a security issue, or a violation of a team contract. Always explain why.
“required: this endpoint has no authentication check — any unauthenticated user can access it.”
LGTM
Non-blockingLooks Good To Me. Approval. You can also write 'LGTM with nits' to approve while leaving optional comments, or 'ship it' for the same effect.
“LGTM! Nice cleanup on the error handling.”
Polite vs. vague: how to give clear feedback
Direct feedback is better than vague feedback. But there is a difference between direct and blunt. These patterns show you how to be both clear and professional.
Situation
Pointing out a bug (blocking)
Weak
“This is wrong. It will break in production.”
Stronger
“required: this could cause a race condition if two requests hit this endpoint at the same time — consider using a mutex or moving the check inside the transaction. What do you think?”
Situation
Suggesting a better approach (non-blocking)
Weak
“You should use a Map here.”
Stronger
“suggestion: a Map might work better here since you are doing frequent lookups by key — it would keep the lookup O(1) instead of O(n). Happy to discuss if there is a reason you went with an array.”
Situation
Asking about a design decision
Weak
“Why did you do it this way?”
Stronger
“question: I see we are calling this API on every render — is that intentional, or would it make sense to cache the result? Just want to make sure I understand the tradeoff.”
Situation
Pointing out a naming issue (nit)
Weak
“Bad variable name.”
Stronger
“nit: `data` is a bit generic here — something like `userList` or `activeUsers` might make this easier to follow at a glance. Totally optional though.”
Accepting feedback gracefully
How to respond to a review comment in English: acknowledging a fix, disagreeing respectfully, and asking follow-up questions.
“Good catch, fixed in the latest push.”
When to use it
Acknowledging a bug the reviewer found and confirming you fixed it.
“You are right, updated.”
When to use it
Short and professional. Use for small corrections where no explanation is needed.
“Makes sense, I went with your suggestion in the latest commit.”
When to use it
Confirming you adopted the reviewer's suggestion and pointing to where.
“I see the issue, but I kept this approach because [reason]. Let me know if that works for you.”
When to use it
Disagreeing respectfully. You explain your reasoning and invite a follow-up.
“Thanks for flagging this! I was not aware of that constraint.”
When to use it
A reviewer pointed out a rule, contract, or risk you did not know about.
Key Takeaways
Commit subject lines use the imperative mood: 'Add feature', not 'Added feature' or 'Adding feature'.
Keep the subject under 50 characters. If you cannot, the commit is probably doing too much.
Use type prefixes (feat, fix, docs, chore, refactor, test) to make the history scannable.
In code reviews: nit = optional, suggestion = non-blocking, question = genuine curiosity, required/blocker = must fix.
LGTM means approved. 'LGTM with nits' means approved with optional comments.
Frame blockers as explanations, not commands: 'this could cause X — consider Y' instead of 'change this to Y'.
When you accept feedback, confirm the fix: 'Good catch, fixed in the latest push.'
Ready to practice your English at work?
Lingua-e has interactive exercises built around real developer conversations: standups, code reviews, retrospectives, and more. Practice until it comes naturally.
Try Lingua-e for freeRelated articles
Written by
Roxana LafuenteLingua-e's founder
Roxana Lafuente is a software engineer with 8+ years of experience. At the beginning of her career, even though she had already passed the First Certificate in English, she still froze every time she had to speak up in the daily standup. That was a gap nobody was fixing. After 2,000+ standups, she figured out what actually builds fluency: practice that looks like your real work. She built Lingua-e so other developers wouldn't have to take the long road to feel confident working in an international development environment.