How to Copy a Git Commit Message (and Keep Its Line Breaks)

To copy the last commit's full message on Windows, run git log -1 --format=%B | Set-Clipboard in PowerShell, or git log -1 --format=%B | clip in Command Prompt. Add a commit hash to copy a different commit: git log -1 --format=%B a1b2c3d | Set-Clipboard. %B is the raw message, subject and body with their original line breaks, so it pastes exactly as it was written.

Commands for copying commit messages

All of these work in PowerShell; swap Set-Clipboard for clip in Command Prompt.

# Full message of the last commit
git log -1 --format=%B | Set-Clipboard

# Full message of a specific commit
git log -1 --format=%B a1b2c3d | Set-Clipboard

# Subject line only
git log -1 --format=%s | Set-Clipboard

# Body only, without the subject
git log -1 --format=%b | Set-Clipboard

# Subjects of the last 10 commits, one per line
git log -10 --format=%s | Set-Clipboard

# Short hash plus subject, for a changelog or chat
git log -10 --format="%h %s" | Set-Clipboard

The placeholders come from git's pretty-format reference: %s is the subject, %b the body, %B the raw body (subject and body unwrapped), and %h the abbreviated hash. The PowerShell clipboard cheat sheet covers more Get-Clipboard and Set-Clipboard options.

If accented characters or emoji come out garbled

Git writes commit messages as UTF-8. Windows PowerShell 5.1 may decode that output with an older code page, turning café into mojibake. Run this once in the session before copying:

[Console]::OutputEncoding = [System.Text.Encoding]::UTF8
git log -1 --format=%B | Set-Clipboard

PowerShell 7 handles UTF-8 output without that step in most setups. If clip in Command Prompt garbles the text, use PowerShell instead. How to copy from Windows Terminal without garbled text covers other causes of mangled copies.

Copying from GitHub in a browser

On a commit page, the subject and body are shown as rendered text. Selecting and copying them usually keeps the paragraph breaks, but long lines may have been wrapped for display, and links and issue references come out as plain text. When the exact text matters, copy it with git log from a local clone instead.

Reusing a message in a new commit

You don't need the clipboard to reuse a message inside the same repository:

• git commit -C <hash> reuses that commit's message and its authorship information, including the timestamp. Use it when that's what you want, for example when re-creating a commit.
• git commit -c <hash> does the same but opens the editor so you can change the message first.
• git commit --amend reopens the last commit's message for editing.

To use a copied message in another repository, the clipboard is the easy route:

1. Copy the message with one of the commands above.
2. Stage your changes, then run git commit with no -m. Git opens your editor.
3. Paste, save and close. Line breaks are kept exactly.

In PowerShell 7 you can skip the editor with Get-Clipboard -Raw | git commit -F -, because -F - reads the message from standard input. In Windows PowerShell 5.1, text piped into native programs isn't sent as UTF-8 by default, so non-ASCII characters can turn into ?; use the editor there.

The 50/72 convention

Git's own documentation recommends starting a commit message with a single short line of no more than 50 characters, then a blank line, then a fuller description. The text up to the first blank line is treated as the title: git log --oneline, GitHub's commit lists and git format-patch all use it.

Wrapping the body at 72 characters is a widely used convention rather than a git rule. It keeps git log readable in an 80-column terminal, because git indents the message by four spaces.

Fix token refresh race in auth middleware

Two requests that arrived while a token was expiring could both try
to refresh it, and the second refresh invalidated the first. Refresh
is now guarded by a single in-flight promise.

Closes #412

Writing git commit -m "Subject" -m "Body paragraph" gives you the blank line automatically, because each -m becomes its own paragraph.

What breaks line breaks when you paste a message

• Soft wrap is not a line break. Text that only looks wrapped in a web page, chat app or word processor arrives as one long line. You need real line breaks in the body if you want the 72-column layout; the same trap shows up when copying man pages and --help output.
• Pasting into a single-line box. Some tools' commit fields accept only one line, so a multi-line paste gets flattened or cut off. Paste into the full editor instead.
• Rich text sources. Copying from Word, Outlook or a rendered page can bring smart quotes and non-breaking spaces with it. Smart quotes and em dashes shows how to strip them.
• Comment lines. By default git removes lines that start with # when you edit the message in an editor, so a pasted line like #412 fixed disappears. Start the line with something else, or commit with --cleanup=whitespace.

Help from VS Code

When VS Code is your git editor, it opens COMMIT_EDITMSG with vertical rulers at columns 50 and 72, so you can see where to wrap. VS Code doesn't rewrap the text for you.

In the Source Control commit box, VS Code can also warn about long lines. The setting git.inputValidation is off by default; turn it on, and the thresholds come from git.inputValidationSubjectLength (default 50) and git.inputValidationLength (default 72).

Fixing a message after you've committed

If the commit isn't pushed yet, run git commit --amend, fix the message in the editor, and save. If it's already pushed, amending rewrites history and needs a force push, which affects anyone who pulled the branch; GitHub's guide to changing a commit message covers both cases.

Footers, trailers and issue links

Lines at the end of the message such as Co-authored-by: Name <email> are trailers. git commit --trailer "Co-authored-by: Name <email>" adds one without hand-typing the format.

Phrases such as Closes #412 or Fixes #412 are a GitHub feature, not a git one: GitHub closes the issue when the commit is merged into the repository's default branch. The supported keywords are close, closes, closed, fix, fixes, fixed, resolve, resolves and resolved.

FAQ

How do I copy the commit hash instead of the message?

Run git log -1 --format=%H | Set-Clipboard for the full hash or %h for the short one. On GitHub, the copy button next to a commit's hash does the same.

Why does my copied message have an extra blank line at the end?

%B ends with the message's own trailing newline. Most destinations ignore it; to drop it, run (git log -1 --format=%B | Out-String).Trim() | Set-Clipboard.

Can I copy several full commit messages at once?

Yes: git log -3 --format="%B%n----" | Set-Clipboard copies the last three, separated by a ---- line. %n is git's newline placeholder.

Related reading

• PowerShell Clipboard Cheat Sheet: Get-Clipboard and Set-Clipboard
• Windows Terminal: Copy Plain Text Without Formatting
• How to Copy man Page and --help Text Without Line Breaks
• How to Copy a File Path That Works in the Terminal

Sources

• git-log pretty formats (Git documentation) — %s, %b, %B, %h and %H placeholders.
• git-commit (Git documentation) — the 50-character summary line, -m, -F, -C, -c, --amend, --cleanup and --trailer.
• Changing a commit message (GitHub Docs) — amending pushed and unpushed commits.
• Linking a pull request to an issue (GitHub Docs) — closing keywords and the default-branch rule.
• VS Code Git extension settings (microsoft/vscode on GitHub) — defaults for git.inputValidation, the 50/72 thresholds, and the git-commit editor rulers.
• Set-Clipboard (Microsoft Learn) — piping text into the clipboard.

Copy. Stack. Drop.

Transform your clipboard into an interactive edge shelf. Stack, pin, and drag assets into any app with zero friction.

Download for Windows Get from Microsoft Store

How to Install Guide · First 10 Minutes Guide · Drag & Drop Guide · Edge Drop vs Win+V · Support