All tools

Git Commit Trailer Parser

Code

Parse a commit message's trailer block (Co-authored-by, Signed-off-by, Fixes, Reviewed-by, etc.) per git's RFC 822-style trailer convention, returning each trailer's key and value plus the message body with the trailer block removed

Paste a full commit message and get back its trailer block parsed into structured key/value pairs, like Signed-off-by, Co-authored-by, Fixes, or Reviewed-by, separated cleanly from the rest of the message body. Git trailers follow an RFC 822-style convention: the last paragraph of a commit message counts as the trailer block when every line in it looks like a Key: value pair, or an indented continuation of the previous line's value. This tool requires every line in that last paragraph to match, so a paragraph that mixes trailers with ordinary prose is reported as having no trailers rather than guessing which lines are which, unlike git's own looser 25%-of-lines heuristic for a mixed paragraph. It's useful for building commit-message linters, extracting co-author credit for changelog generation, or just checking that a commit template's trailers came through correctly before a squash-merge.

gitcommittrailervcsparser

How to use Git Commit Trailer Parser

  • 1.Paste a full commit message, including any trailing Key: value lines.
  • 2.Review the parsed trailers, each with its key and value split out, and the body text with the trailer block removed.
  • 3.Use the REST API or an SDK to lint or extract trailers across a batch of commit messages, for example when generating a changelog's co-author credits.

Frequently asked questions

What counts as a trailer line?
A line matching Key: value at the start of the message's last paragraph, where Key is letters, digits, and hyphens (like Signed-off-by or Co-authored-by). An indented line right after a trailer is folded into that trailer's value as a continuation.
Why did my commit message come back with no trailers?
Every line in the last paragraph has to look like a trailer or a continuation of one. If that paragraph mixes in a plain sentence, like a trailing note, the whole paragraph is treated as ordinary body text instead of a trailer block.
Does this match git's own git interpret-trailers exactly?
Not quite: real git accepts a last paragraph as trailers if roughly 25% of its lines look trailer-shaped, tolerating some mixed-in prose. This tool takes the stricter all-or-nothing approach instead, which avoids false positives at the cost of occasionally missing a real trailer block.
What happens if a commit message is only a trailer block, with no body?
It's still parsed correctly: all lines become trailers and the body comes back empty, which is exactly what git treats as a valid (if terse) commit.

Use via API, SDK, or MCP

cURL# Free: 1,000 req/day · Pro: 10,000 req/day
curl -X POST https://api.utilix.tech/v1/tools/git-commit-trailer-parser \
  -H "Authorization: Bearer utx_live_..." \
  -H "Content-Type: application/json" \
  -d '{"message":"Fix bug\n\nLonger explanation of the fix.\n\nFixes: #123\nSigned-off-by: A <a@example.com>"}'

Get an API key from your dashboard · Full API docs →

Related tools

Commit Message Generator (AI)Paste a git diff and get a Conventional Commits-style commit message back: type, scope, subject, and body, powered by GPT-4o miniCodeConventional Commit Message LinterLint a git commit message against the Conventional Commits v1.0.0 spec: header format, blank-line separation, footer tokens, and BREAKING CHANGE casingCodeGit Command BuilderBuild git commands from a form: commit, push, branch, and moreCode