author
commits
git

How do I change the author and committer name/email for multiple commits?

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

Changing the author and committer for multiple Git commits means rewriting history, not editing metadata in place. For a small recent range, interactive rebase can work. For bulk changes across many commits, git filter-repo is usually the cleaner and more reliable tool.

Understand author versus committer

Every Git commit stores at least two identities:

  • author: who originally wrote the change
  • committer: who created the commit object currently in history

If you rewrite history, both can change. That is why simple config changes such as:

bash
git config user.name "New Name"
git config user.email "[email protected]"

only affect future commits. Existing commits remain unchanged until you rewrite them.

Use interactive rebase for a small recent range

If you only need to fix the last few commits, interactive rebase is reasonable:

bash
git rebase -i HEAD~3

Mark the commits you want to modify as edit, then for each stopped commit run:

bash
1git commit --amend --author="New Name <[email protected]>" --no-edit
2GIT_COMMITTER_NAME="New Name" \
3GIT_COMMITTER_EMAIL="[email protected]" \
4git rebase --continue

This is manageable for a few commits, but tedious for dozens or hundreds.

Use git filter-repo for bulk rewriting

For larger history changes, git filter-repo is usually the better tool. It rewrites commit metadata programmatically and is much safer than the old filter-branch workflow.

A common mailmap-style replacement file looks like this:

text
Old Name <[email protected]> New Name <[email protected]>

Then run:

bash
git filter-repo --mailmap my-mailmap.txt

This rewrites matching commits across the selected history. It is especially useful when the wrong identity appears many times.

If you need more advanced rewriting logic, git filter-repo also supports callback-style scripts, but a mailmap-based rewrite is often enough.

Plan for the consequences of rewriting history

Rewriting author and committer fields creates new commit IDs. That means:

  • local branch history changes
  • remote pushes require force
  • collaborators must realign their clones

After the rewrite:

bash
git push --force-with-lease

Use --force-with-lease rather than plain --force when possible, because it gives a safer check against clobbering unexpected remote work.

If the branch is shared widely, coordinate the rewrite before pushing. History cleanup is a repository-wide event, not a personal cosmetic tweak.

Back up before rewriting

Always make a backup branch or fresh clone before changing historical commit identities:

bash
git branch backup-before-rewrite

That gives you an escape hatch if the rewrite scope was too broad or if a collaborator still needs the old references for comparison.

Common Pitfalls

The biggest mistake is changing user.name and user.email and expecting old commits to update automatically. Git does not retroactively edit existing history.

Another mistake is using interactive rebase for a large history rewrite. It works for a few commits but becomes error-prone and slow when the range is large.

Developers also forget that rewritten commits get new hashes. Any branch, tag, pull request, or colleague depending on the old history will need to be reconciled.

Finally, do not use deprecated history-rewrite approaches unless you have a specific reason. git filter-repo is usually the better modern tool for bulk metadata correction.

If only a few recent commits are wrong, keep the rewrite narrow. Rewriting less history reduces coordination cost and lowers the chance of disturbing unrelated branches or tags.

After the rewrite, verify the result with git log --format=fuller on the affected commits. That confirms both author and committer fields changed the way you intended before you force-push the new history.

Summary

  • Changing author and committer on existing commits requires rewriting history.
  • Use interactive rebase for a small recent range of commits.
  • Use git filter-repo for broad or repetitive metadata changes.
  • Expect new commit hashes and a force push after the rewrite.
  • Back up the repository state and coordinate with collaborators before changing shared history.

Course illustration
Course illustration

All Rights Reserved.