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.
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.
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:
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.
You can also pipe the message from standard input:
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.
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.
For a slightly fuller view:
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
-mflags 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
-Fwhen the message is easier to manage as a full text block. - '
git commit --amendcan fix the latest message before the history is shared.' - Inspect the finished commit message before pushing it upstream.

