git
command line
version control
commit message
duplicate

How to commit a change with both message and description from the command line?

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

A good Git commit message usually has a short subject line and a longer body that explains why the change exists. You can provide both directly from the command line without opening an editor, which is useful in remote shells, automation-friendly workflows, and quick fix sessions.

Use More Than One -m

The simplest method is to pass -m multiple times. Git treats the first -m as the subject line and later ones as body paragraphs.

bash
1git add src/auth/login.go
2
3git commit \
4  -m "Fix token refresh race in login flow" \
5  -m "Serialize refresh attempts per session.
6Add timeout protection and a regression test for concurrent requests."

Git inserts the blank line between subject and body automatically, so the result is a properly formatted commit message.

If you provide a third -m, it becomes another paragraph in the body.

bash
1git commit \
2  -m "Harden payment retry backoff policy" \
3  -m "Cap retry burst to protect the downstream API." \
4  -m "Refs: PAY-1842"

Keep the Subject and Body Doing Different Jobs

A commit message is easier to read when each part has a clear purpose:

  • subject line says what changed
  • body explains why it changed
  • body may also mention risk, follow-up work, or references

Example:

text
1Fix token refresh race in login flow
2
3Serialize refresh attempts per session to prevent duplicate refresh calls.
4Add timeout protection and regression coverage for concurrent requests.

This matters because git log --oneline shows only the first line, while full history views and code review tools expose the body.

Use -F for Longer Messages

If the body is long or easier to prepare as one block, -F is often cleaner than stacking many -m flags. Git will read the full message from a file.

bash
1cat > /tmp/commit-msg.txt <<'MSG'
2Refactor session cache invalidation
3
4Move invalidation rules into a dedicated service.
5This removes duplicate branching from login and logout paths.
6MSG
7
8git commit -F /tmp/commit-msg.txt

You can also pipe the message from standard input:

bash
printf 'Refactor session cache invalidation\n\nMove invalidation rules into a dedicated service.\n' | git commit -F -

This is useful when another tool generates the message but you still want a normal Git commit.

Fix the Message With --amend

If you already committed with only a short title, you can replace the latest message locally with --amend.

bash
git commit --amend \
  -m "Fix token refresh race in login flow" \
  -m "Serialize refresh attempts and add regression coverage."

This rewrites the most recent commit. It is generally safe before the commit is shared. After pushing, amending changes commit identity, so the decision becomes a coordination issue rather than just a formatting choice.

Inspect the Final Result

Before pushing, inspect the message so you do not discover formatting problems during review.

bash
git log -1

For a slightly fuller view:

bash
git show --no-patch --pretty=full

Those commands catch common mistakes such as putting the whole explanation into the subject line or breaking body paragraphs with incorrect quoting.

When to Open an Editor Instead

Command-line flags are ideal for short and medium-length messages. If the body needs several paragraphs, bullet points, or careful wording, opening the editor may be more comfortable and less error-prone.

The command-line approach is a convenience, not a requirement. The real goal is a clear commit message, not avoiding an editor at all costs.

Common Pitfalls

The most common mistake is trying to squeeze both the title and the explanation into one -m argument, which produces a hard-to-scan subject line.

Another common issue is treating the body as filler. The body should explain why the change matters, not merely repeat what the diff already shows. Developers also sometimes use --amend after pushing and then create unnecessary history churn for collaborators.

Summary

  • Use multiple -m flags to provide a subject line and body directly from the command line.
  • Keep the first line short and reserve the body for rationale and context.
  • Use -F when the message is easier to manage as a full text block.
  • 'git commit --amend can fix the latest message before the history is shared.'
  • Inspect the finished commit message before pushing it upstream.

Course illustration
Course illustration

All Rights Reserved.