Introduction

Git stores both an author and a committer on every commit, and the two are not always the same person. The author is the person who originally wrote the change, while the committer is the person who actually created that commit object in the repository history. This distinction matters most when patches are rebased, cherry-picked, applied by maintainers, or rewritten during review.

Author Means "Who Wrote the Change"

The author identity records who originally created the content represented by the commit. That identity includes:

• author name
• author email
• author timestamp

If Alice writes a patch and sends it to a maintainer, Alice is usually the author even if someone else later applies the patch.

You can inspect both fields with:

git log --format=fuller -1

Typical output shows separate Author and Commit lines. The Commit line refers to the committer metadata.

Committer Means "Who Wrote This Commit into History"

The committer is the person who actually created the commit object that now exists in the branch history.

That happens in many normal workflows:

• a maintainer applies someone else's patch
• a developer rebases and rewrites commits
• a cherry-pick creates a new commit based on an older one
• a squash merge creates a new commit from several authored changes

In those cases, the authored idea may come from one person, but the historical commit object was created by another.

See the Difference in Practice

This command shows both fields clearly:

git log --format="%h%nAuthor: %an <%ae>%nCommitter: %cn <%ce>%n" -1

You can also inspect one specific commit:

git show --no-patch --format=fuller HEAD

That is often the quickest way to understand what happened after a rebase or patch application.

When They Are the Same

In the simplest workflow, author and committer match. For example, if you make a local commit directly on your branch:

git add .
git commit -m "Fix login validation"

you are both:

• the author, because you wrote the change
• the committer, because you created the commit object

Most day-to-day personal commits look like this.

When They Differ

Suppose Bob emails a patch to Carla, and Carla applies it with git am. Bob remains the author, but Carla becomes the committer because she inserted the commit into the repository history.

A similar thing happens with rebasing. Rebasing does not move old commits unchanged; it creates new commit objects. The original author is preserved, but the rebasing developer becomes the committer of the rewritten commits.

That is why after a rebase you often see:

• original author unchanged
• committer updated to the person who performed the rebase
• commit date updated

Why This Distinction Matters

The difference is not just trivia. It helps answer different historical questions:

• who originally made this code decision
• who integrated or rewrote this change
• whether history was replayed, squashed, or rebased

That is useful in open source maintenance, regulated audit trails, and debugging workflow mistakes. If a patch was authored months ago but committed yesterday by someone else, that tells you something important about how it entered the branch.

Author and Committer Can Be Changed

Git lets you override these identities, which is helpful but dangerous if used carelessly.

You can amend author metadata:

git commit --amend --author="Alice Example <[email protected]>"

You can also set committer information through environment variables for one command:

GIT_COMMITTER_NAME="Carla Example" \
GIT_COMMITTER_EMAIL="[email protected]" \
git commit --amend --no-edit

This flexibility is useful for correcting mistakes, but it also means metadata is not a cryptographic proof of real-world identity by itself.

Common Pitfalls

• Assuming author and committer are always the same.
• Thinking rebasing preserves the original commit object unchanged.
• Using git log defaults and missing the separate committer information.
• Rewriting metadata without understanding the audit implications.
• Treating Git identity fields as stronger proof than they really are.

Summary

• The author is who originally wrote the change.
• The committer is who created the commit object in the current history.
• They are often the same in simple local workflows.
• They differ in patch application, rebasing, cherry-picking, and maintainer-driven integration.
• Inspect both fields when understanding how a change actually entered the repository.