Git
Version Control
Amend Commits
Change Author
Git Tutorial

How to amend several commits in Git to change author

Interview Questions practice on Codemia

Over 8,000 real interview questions from top companies, searchable by company and role.

Browse interview questions

Introduction

Changing the author on several Git commits means rewriting history. That is safe on local or private branches when done carefully, but it becomes disruptive once other people have based work on the old commit IDs.

Understand What Changes

Each Git commit stores author name, author email, committer name, committer email, timestamps, the message, and the parent commit hash. If you change the author of an existing commit, Git creates a new commit object with a new hash. Any descendant commits must be rewritten as well.

That is why "changing a few authors" often touches a whole segment of history rather than just editing metadata in place.

Recent Commits: Interactive Rebase

If the commits are recent and you know exactly how many to edit, interactive rebase is the most precise approach.

bash
git rebase -i HEAD~3

In the editor, change pick to edit for each commit whose author you want to fix. Then, when rebase stops on a commit, run:

bash
git commit --amend --no-edit --author="Correct Name <[email protected]>"
git rebase --continue

Git will pause at the next commit marked edit, and you repeat the same amend step.

This method is easy to reason about because you review each rewritten commit individually.

Many Commits: Use git filter-repo

If you need to change author information across a larger history range, git filter-repo is usually a better tool than hand-editing commit after commit. It is faster, safer than the old filter-branch workflow, and designed for repository-wide history rewrites.

bash
1git filter-repo --email-callback '
2    return b"[email protected]" if email == b"[email protected]" else email
3' --name-callback '
4    return b"Correct Name" if name == b"Wrong Name" else name
5'

That command rewrites all matching commits so the old identity is replaced with the new one.

Use this when the bad author appears repeatedly across many commits or branches. For only a handful of recent commits, interactive rebase is usually simpler.

Confirm the Result

After rewriting, verify the metadata before pushing:

bash
git log --format="%h %an <%ae> %cn <%ce> %s" -n 10

This shows both author and committer fields so you can confirm the change affected what you intended.

If you only changed the author but not the committer, that may be fine. If you need both fields updated in a bulk rewrite, choose a tool and command that explicitly rewrites both.

Pushing Rewritten History

Once commit hashes change, a normal push will usually be rejected. You need a force push, ideally with lease protection:

bash
git push --force-with-lease origin your-branch

--force-with-lease is safer than plain --force because it refuses to overwrite remote updates you have not seen.

On a shared branch, coordinate with the team first. Anyone holding the old history will need to rebase or reset their local branch onto the new one.

When Not to Rewrite

If the branch is already widely shared and the metadata mistake is minor, rewriting may cost more than it saves. In some teams, it is better to leave historical commits alone and fix user.name and user.email for future work.

The right answer depends on whether the branch is private, public, or already part of a stable release history.

Common Pitfalls

Rewriting a shared branch without warning other developers creates unnecessary merge pain because every affected commit gets a new hash.

Using plain git push --force is riskier than --force-with-lease because it can overwrite remote work you did not account for.

Interactive rebase only covers the commit range you selected. If you start too late, older incorrect commits remain unchanged.

Changing author information does not preserve commit IDs. Any tooling or documentation that references old hashes will need to be updated.

Using old history-rewrite tools such as filter-branch is slower and more error-prone than modern git filter-repo.

Summary

  • Changing commit authors rewrites history and creates new commit hashes.
  • Use interactive rebase when only a few recent commits need correction.
  • Use git filter-repo when many commits or broad history ranges need the same author fix.
  • Verify both author and committer fields with git log after the rewrite.
  • Force-push carefully and coordinate before changing shared history.

Related reading
Free course
Beginner
7 lessons
2 hours
Tackling System Design Interview Problems

A short course that equips you with the skills to approach system design interviews methodically.

Start the free course
Track what you have practised

A free account saves your progress, solutions and study plan across every problem on Codemia.

Interview Questions practice on Codemia

Over 8,000 real interview questions from top companies, searchable by company and role.

Browse interview questions

All Rights Reserved.