
Understanding Git Commit Trailers
/ 5 min read
Table of Contents
Why Commit Trailers Matter
Most developers think of a commit message as two parts: a short title and, optionally, a longer body. That is true, but there is often a third part at the end that is easy to overlook: commit trailers.
Commit trailers are structured lines added at the bottom of a commit message. They look simple, but they can carry useful metadata in a format that humans and tools can both understand.
You have probably seen examples like these:
Signed-off-by: Sheldon Cooper <sheldon@example.com>Reviewed-by: Leonard Hofstader <leonard@example.com>Tested-by: Howard Wolowitz <howard@example.com>These lines are not random conventions. Git has built-in support for parsing and editing them, and the Git project documents common trailer conventions in its patch submission guidelines.
What Commit Trailers Are
A trailer is a key-value pair placed at the end of a commit message, usually after a blank line. In practice, they behave like footers for commit metadata.
Here is a simple example:
Improve validation for API tokens
Reject empty values earlier and return a clearer error message.
Reviewed-by: Berndaette Rostenkowski <bernadette@example.com>Tested-by: Amy Farrah Fowler <amy@example.com>The subject explains the change. The body gives context. The trailers describe additional information about how the change was produced, reviewed, or validated.
This structure is especially helpful when you want commit history to be both readable and machine-processable.
Common Commit Trailers
Here are some of the trailers you will see most often in open source and collaborative workflows.
Signed-off-by
This trailer is commonly used to indicate that the author agrees with a contribution process, often the Developer Certificate of Origin.
Example:
Signed-off-by: Simone Gigante <simone@example.com>Projects that require contributors to certify that they have the right to submit the code often ask for this trailer on every commit.
Reviewed-by
This trailer records who reviewed the change.
Example:
Reviewed-by: Raj Koothrappali <raj@example.com>It is useful in teams or projects where review is an important part of the development process, and you want that information to remain attached to the commit itself.
Acked-by
This trailer indicates that someone has looked at the change and agrees with it, even if they were not the main reviewer.
Example:
Acked-by: Leslie Winkle <lesie@example.com>This is common in open source workflows where multiple maintainers or domain experts may want to signal support for a patch.
Tested-by
This trailer records who tested the change.
Example:
Tested-by: Barry Kripke <barry@example.com>It is useful when testing is performed by someone other than the author, especially for bug fixes, platform-specific checks, or release validation.
Reported-by
This trailer credits the person who reported the issue that led to the patch.
Example:
Reported-by: Arthur Jeffries <arthur@example.com>It helps preserve traceability and gives credit to the person who identified the bug or problem.
Suggested-by
This trailer credits the person who suggested the approach or idea behind the patch.
Example:
Suggested-by: Wil Wheaton <wil@example.com>It is useful when someone contributed the direction of the fix or feature, even if they did not implement the change themselves.
Helped-by
This trailer is often used to credit someone who contributed useful guidance or debugging help without being a co-author.
Example:
Helped-by: Bert Kibbler <bert@example.com>It is useful when someone provides meaningful help, but not enough to justify authorship of the commit itself.
Co-authored-by
This trailer credits another contributor for the same commit.
Example:
Co-authored-by: Sheldon Cooper <sheldon@example.com>This is useful for pair programming, mob programming, or any change where more than one person meaningfully contributed.
On-behalf-of
This trailer is less universal, but it is worth knowing because GitHub documents it for commits created on behalf of an organization.
Example:
On-behalf-of: Example Org <opensource@example.org>If you are making a commit as a representative of an organization, this trailer can express that relationship in the commit message. GitHub documents this in its guide to creating a commit on behalf of an organization.
Conventions
Trailers are simple, but they are not completely free-form. Git supports them through git interpret-trailers, and the Git project documents widely used conventions in Submitting Patches: commit trailers.
In practice, that usually means:
- Trailers appear at the end of the commit message
- Each trailer is a
token: valuepair - The trailer block is usually separated from the body by a blank line
- Teams often reuse conventional names such as
Signed-off-by,Reviewed-by, orAcked-by
You can invent your own trailer names, but established conventions are usually better when you want other developers and tools to understand them immediately.
How Git and GitHub Use Commit Trailers
One useful detail that many developers miss is that Git itself understands trailers. This is not only a convention layered on top by hosting platforms.
Git includes support through commands such as:
git interpret-trailersThat means trailers can be parsed, added, and normalized in a structured way instead of being treated as arbitrary text. If you want to automate footer handling, this is the first place to look.
GitHub also uses some trailers in product-specific ways. The clearest examples are Co-authored-by, which GitHub recognizes for co-author attribution in its guide to creating a commit with multiple authors, and On-behalf-of, which GitHub documents for organization-backed commits in its guide to creating a commit on behalf of an organization. In practice, this is not only cosmetic: GitHub says co-authored commits are visible on GitHub and can be included in profile contributions and in a repository’s statistics, and the contributors graph can include commit co-authors. That means a correctly formatted Co-authored-by trailer can affect the contributors section and related contribution views of a repository, not just the commit page itself.
That is why I created coauthorcheck, a lightweight validator for Co-authored-by commit trailers in the CLI, pre-commit hooks, and GitHub Actions.
Other Git hosting platforms will usually preserve trailers because they are part of the commit message itself, but special UI treatment and automation support vary from platform to platform. That is one more reason to prefer widely recognized trailer names when possible.
Conclusion
Commit trailers are a small part of a commit message, but they make a real difference. They let teams attach structured information to commits in a way that stays readable for humans and useful for tooling.
Once you start noticing them, you begin to see that they solve several practical problems at once: attribution, review traceability, testing history, contribution rules, and automation. They are one of those Git features that look minor at first, but become much more valuable as collaboration grows.