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:
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:
Mark the commits you want to modify as edit, then for each stopped commit run:
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:
Then run:
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:
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:
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-repofor 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.

