How to amend the author of your last commit in Git

You just pushed a small fix from your laptop on a Sunday evening. Five minutes later, you notice the commit shows up on the PR with your work email as the author. You meant to use your personal email. The commit is yours — you wrote the code, you made the change — but the author field says someone you do not want to be on a personal side project.

Or the opposite: you committed work code from a fresh clone on a new machine, and Git picked up the default whoami config. The commit landed in your team's repo with rajat@new-macbook.local as the author and a name you have not used in five years.

Either way, the fix is short. This post walks through:

• Amending the last commit's author (one command).
• Amending an older commit's author (interactive rebase, three commands).
• The case where you have already pushed (force-with-lease, with caveats).
• How to set up Git so this never happens again.

What user.name and user.email actually do

Every Git commit is a small binary object. When Git creates one, it bakes in two pairs of identity fields:

• Author — who wrote the change. Set from user.name and user.email at commit time.
• Committer — who created the commit object. Usually the same as the author, but they differ when you cherry-pick, rebase, or apply a patch on someone else's behalf.

These fields are part of the commit's hash input. Change either, and you get a new commit with a new SHA. The original commit is still in .git/objects/, but the new one is what the branch points at.

You can see both fields with:

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

The git commit docs describe the precedence: --author flag > GIT_AUTHOR_NAME/GIT_AUTHOR_EMAIL environment > user.name/user.email config (repo-local first, then global, then system).

This precedence is what bites people. If your global config is work@company.com and your personal repo does not have a local override, every commit you make in that repo gets your work email. Git does not warn you. It just bakes it in.

Fixing the last commit

The simplest case: you just committed, you have not pushed, and the author is wrong.

git commit --amend --author="Rajat Saboo <rajat@personal.com>" --no-edit

That is the whole fix. Breaking it down:

• --amend replaces the last commit with a new one.
• --author="Name <email>" sets the author fields. The exact format with angle brackets is required — see the git commit --author docs.
• --no-edit keeps the existing commit message. Without it, Git opens your editor.

Verify:

git log -1 --format="%an <%ae>"

If the commit was not pushed, you are done. The old commit still exists in .git/objects/ for a while (it is in your reflog), but the branch now points at the new one.

What about the committer field?

--amend keeps the committer set to your current config. If you also want to change the committer (for example, you want both fields to show rajat@personal.com), update your local config first:

git config user.email "rajat@personal.com"
git config user.name "Rajat Saboo"
git commit --amend --reset-author --no-edit

The --reset-author flag tells Git to pull both author and committer from your current config. This is the cleanest way when you have already fixed your local config.

Fixing an older commit

Suppose the wrong-author commit is not the last one. There are two more commits on top of it. Now --amend alone will not do — --amend only edits HEAD.

The tool is interactive rebase (git rebase -i):

git rebase -i HEAD~3

This opens an editor with a TODO list of the last three commits:

pick 9f4e2c8 feat: payment webhook handler
pick 6c1a5e3 chore: bump stripe sdk
pick 3d8f2b1 docs: update README

Change pick to edit on the commit you want to fix:

edit 9f4e2c8 feat: payment webhook handler
pick 6c1a5e3 chore: bump stripe sdk
pick 3d8f2b1 docs: update README

Save and close. Git replays history and stops at the edit line. You are now sitting on that commit with your working tree at that exact state. Run:

git commit --amend --author="Rajat Saboo <rajat@personal.com>" --no-edit
git rebase --continue

The amend rewrites the commit with the new author. The --continue replays the remaining commits on top of the new one. Each replayed commit gets a new SHA because its parent changed — this is expected, and we will come back to what it means for pushed branches.

Fixing several commits in one rebase

If multiple commits have the wrong author, mark each of them as edit:

edit 9f4e2c8 feat: payment webhook handler
edit 6c1a5e3 chore: bump stripe sdk
pick 3d8f2b1 docs: update README

Git stops at each one. Run the same amend command, then --continue, then it stops at the next one. Repeat.

Fixing every commit on a branch

For a branch where every commit needs the same author change, git rebase --exec is faster:

git rebase --exec 'git commit --amend --no-edit --reset-author' --root

Make sure your local user.name and user.email are correct first — --reset-author reads from config. This rewrites every commit reachable from HEAD with you as the author.

A heavier hammer for the same goal is git filter-repo, the modern replacement for git filter-branch. It can swap specific author emails across the entire history. Use it when you have hundreds of commits to fix or need to replace one specific email with another.

Quick comparison — last commit vs older commits

Situation	Tool	Number of commands
Last commit, not pushed	git commit --amend	1
Last commit, already pushed	git commit --amend + force-with-lease push	2
Older commit, not pushed	git rebase -i HEAD~N	3
Older commit, already pushed	git rebase -i + force-with-lease push	4
Every commit on a branch	git rebase --exec --root	1
Many commits across full history	git filter-repo	1 (plus install)

The pushed-commit case — force with lease

Amending or rebasing rewrites commits. Rewritten commits have new SHAs. If the original commits were pushed, the remote still has the old SHAs. Your next regular git push is rejected because your local history is no longer a fast-forward.

You have two options.

Option 1: force-with-lease (the safer one).

git push --force-with-lease

--force-with-lease refuses the push if the remote branch has moved since your last fetch — that is, if someone else has pushed in the meantime. It still rewrites history, but only if your local view of the remote is current. This is the right default for "I know I am rewriting, but I do not want to overwrite anyone else's work".

Option 2: plain force (the dangerous one).

git push --force

Plain --force does not check the remote state. If a teammate pushed five commits while you were rebasing, --force deletes them. Avoid this command on shared branches.

Both options have the same downside on shared branches: any teammate who already pulled the old commits now has a divergent local copy. They will run git pull and either get a merge with the old SHAs (creating duplicate history) or have to reset their local branch. This is the reason for the standard rule:

Do not rewrite history that other people have pulled.

On a personal feature branch nobody else is using, force-with-lease is safe. On main or any branch with active reviewers, the cost of rewriting is high — every reviewer's approval becomes stale, comments may detach from lines, CI re-runs against new SHAs.

When NOT to do this

Three cases where the right answer is "leave it alone":

• Public branches with many contributors. Rewriting main to fix an author field is almost never worth the disruption. The author of one commit is in the past. Move on.
• Commits that have been reviewed and approved. Reviewers approved a specific SHA. Rewriting invalidates approvals and may force re-review. Check your PR tool's behaviour first.
• Compliance contexts where history is auditable. Some regulated codebases require that committed history is immutable. If you are unsure, ask before rewriting.

If the wrong-author commit is already in main and the team will not block its presence, the easiest fix is often a small documentation note rather than a rebase.

Preventing recurrence — per-repo config

The simplest prevention is to set user.email and user.name locally in every repo where the global setting is wrong:

cd ~/code/personal/my-side-project
git config user.email "rajat@personal.com"
git config user.name "Rajat Saboo"

The git config command without --global writes to .git/config in the current repo. From now on, every commit in this repo uses these values, regardless of your global config.

Verify with:

git config user.email
git config user.name

Preventing recurrence — conditional includes

If you maintain many repos and they fall into clear categories (work in ~/work/, personal in ~/personal/), Git's conditional includes automate the split. Add this to ~/.gitconfig:

[user]
  name = Rajat Saboo
  email = rajat@personal.com   # default

[includeIf "gitdir:~/work/"]
  path = ~/.gitconfig-work

[includeIf "gitdir:~/personal/"]
  path = ~/.gitconfig-personal

Then in ~/.gitconfig-work:

[user]
  name = Rajat Saboo
  email = rajat@company.com

And in ~/.gitconfig-personal:

[user]
  name = Rajat Saboo
  email = rajat@personal.com

Any repo under ~/work/ automatically picks up your work identity. Any repo under ~/personal/ picks up your personal one. The default in ~/.gitconfig is the fallback. The trailing slash in gitdir:~/work/ is required — without it, only an exact match works.

Test the setup in a real repo:

cd ~/work/some-project
git config user.email
# rajat@company.com

cd ~/personal/some-other-project
git config user.email
# rajat@personal.com

Now your commits will have the right author from the start, regardless of which folder you happen to be in.

A pre-commit hook for paranoia

If conditional includes are not enough — for example, because your repo paths are unpredictable — a small hook can refuse commits with the wrong email. In .git/hooks/pre-commit:

#!/bin/sh
expected="rajat@personal.com"
actual=$(git config user.email)
if [ "$actual" != "$expected" ]; then
  echo "ERROR: commit email is $actual, expected $expected"
  echo "Run: git config user.email \"$expected\""
  exit 1
fi

Make it executable: chmod +x .git/hooks/pre-commit. Any commit attempt with the wrong email is refused before it happens. The downside is that .git/hooks/ is not committed — every clone needs the hook installed again. Tools like Husky solve that by storing hooks in the repo.

Three common myths

Myth 1: "git commit --amend cannot change the author." Wrong. The --author flag is part of the documented git commit interface and applies to both new commits and amendments. The confusion comes from the fact that --amend alone keeps the original author by default.

Myth 2: "Rewriting an author is destructive — the old commit is gone forever." Wrong. The original commit object stays in .git/objects/ until garbage collection (at least 30 days, often longer). It is in your reflog. You can recover it with git reset --hard <old-sha> if needed. This is the same recovery story as any other history rewrite.

Myth 3: "Force-with-lease is just as dangerous as force." Wrong, with a caveat. --force-with-lease checks that the remote ref is still at the SHA you last saw before pushing. If a teammate has pushed since you fetched, the push is refused. The caveat: if you ran git fetch recently, your "last seen" SHA is updated, and the lease will not catch a teammate's push that happened between your fetch and your push. The window is small. It is still strictly safer than plain --force.

Fixing the date as well as the author

Sometimes the same situation that produced the wrong author also produced the wrong date — for example, you committed on your laptop while it was set to the wrong timezone. The --date flag handles this:

git commit --amend --author="Rajat Saboo <rajat@personal.com>" \
                   --date="2026-06-09T14:30:00+05:30" \
                   --no-edit

The format is ISO 8601 with timezone offset. Git accepts several looser formats too — "now", "2 hours ago", "2026-06-09 14:30" — but ISO 8601 is the safest because it is unambiguous.

--date only sets the author date. The committer date defaults to "now". If you want both to match, set them via environment variables before the commit:

GIT_AUTHOR_DATE="2026-06-09T14:30:00+05:30" \
GIT_COMMITTER_DATE="2026-06-09T14:30:00+05:30" \
git commit --amend --no-edit

This is fiddly enough that it is worth automating into a shell function if you do it often.

What if the wrong author commit was a merge?

Merge commits have the same author and committer fields as any other commit, and --amend works the same way:

git commit --amend --author="Rajat Saboo <rajat@personal.com>" --no-edit

The only subtlety: if you amend a merge commit, the merge parent links are preserved. The commit is still a merge. You are only changing the author field, not the structure.

For older merge commits, the interactive rebase flow needs --rebase-merges:

git rebase -i --rebase-merges HEAD~5

Without --rebase-merges, an interactive rebase will linearise your history by re-applying the patches and dropping the merge structure. That is rarely what you want when fixing an author field on a merge.

Try it in a live terminal

Open the amend author scenario for a seeded repo with one commit that has the wrong author. Walk through the amend, see the SHA change, verify the new author. The first deliberate amend is what makes the next accidental wrong-author commit feel like a sixty-second fix.

What to read next

• git reflog: the undo button you didn't know you had — if you amend the wrong thing, the reflog brings the original back.
• How to recover a deleted Git branch — the same family of "I just did something I want to undo" problems.
• Choosing a Git workflow: a decision guide for real teams — where rewriting history is fine, and where it is not.
• The Amending Commits Safely lesson in the sidebar walks you through amend in a live terminal.
• The Interactive Rebase lesson covers the broader git rebase -i surface — edit, squash, fixup, reword, drop.

If you remember one thing from this post: the author of a commit is just two strings in a binary object. Git makes it cheap to fix when it is wrong, and cheap to prevent through user.email config and conditional includes. The hard part is noticing in the first place — and now you know what to look for.