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.
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.
In the editor, change pick to edit for each commit whose author you want to fix. Then, when rebase stops on a commit, run:
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.
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:
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:
--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-repowhen many commits or broad history ranges need the same author fix. - Verify both author and committer fields with
git logafter the rewrite. - Force-push carefully and coordinate before changing shared history.
Related reading
- How to apply a patch generated with git format-patch?
- How to apply git diff patch without Git installed?
- How to apply unmerged upstream pull requests from other forks into my fork?
- How to automatically resolve a Git conflict by taking the version in the current branch?
- How to avoid having to do git branch --set-upstream, and instead default to automatically setup remote tracking?
- How to avoid merge-commit hell on GitHub/BitBucket
- How to avoid Merge branch 'name_of_branch' in commit messages?
- How to best set up a central git repository from a current existing local git repository?
.png&w=3840&q=75)
Tackling System Design Interview Problems
A short course that equips you with the skills to approach system design interviews methodically.
Start the free courseTrack 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.