Fixing the Wrong Git Author in Multiple Commits — A Story from the Trenches

So here's something that happened to me last week. I was juggling work between my personal laptop and my work machine, and somewhere along the way I pushed a batch of commits to a repo with the completely wrong author email. You know that sinking feeling when you run git log and realize half your commits are attributed to the wrong person? Yeah. That one.

If you've ever been there, this post is for you. I'll walk you through exactly how I cleaned it up — no fluff, just the stuff that actually worked.

The Problem

Picture this: you made a bunch of commits, pushed them to the remote, and then noticed the author name and email on those commits belong to some old config you forgot to update. Maybe it's your personal email showing up on work commits, or the other way around. Either way, the history is wrong and you want it fixed.

The good news? Git lets you rewrite history. The catch? You have to be a little careful, especially if other people are working on the same branch.

Step 1: Get Your Git Identity Straight First

Before you go rewriting anything, fix the config. Otherwise you'll just be repeating this whole dance next week.

git config user.name "Your Name"
git config user.email "your-email@example.com"

If you want this config to apply only to the current repo (which is usually what you want when you're dealing with multiple identities), add the --local flag:

git config --local user.name "Your Name"
git config --local user.email "your-email@example.com"

I learned the hard way that setting this globally can cause the exact problem we're trying to fix here. Per-repo configs save lives.

Step 2: Start an Interactive Rebase

Now for the fun part. Let's say you need to fix the last 2 commits. Fire up an interactive rebase:

git rebase -i HEAD~2

Git will open your editor with something like this:

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

Save and close the editor. Git will pause at the first commit you marked.

Step 3: Amend the Author

When Git stops at your commit, run this:

git commit --amend --author="Your Name <your-email@example.com>" --no-edit
git rebase --continue

The --no-edit flag is a small mercy — it keeps your original commit message so you don't have to retype anything. If you marked multiple commits with edit, Git will pause again for each one. Just repeat the amend command each time.

Step 4: Push the Fixed History

Once the rebase finishes, you'll need to force push since you've rewritten history:

git push --force origin main

A word of caution: force pushing rewrites history on the remote. If you're working on a shared branch, coordinate with your team first. Nobody likes waking up to find their local branch is suddenly out of sync because someone force-pushed over their work.

If you want to be a bit safer, use --force-with-lease instead — it'll refuse to push if someone else has committed in the meantime.

Things That Will Probably Go Wrong (And How to Fix Them)

Real talk — rebases rarely go perfectly the first time. Here are the errors I've hit, and how to get unstuck.

"There is already a rebase-merge directory"

This means a previous rebase never finished. Abort it and start fresh:

git rebase --abort

"Cannot lock ref"

Usually a leftover state issue. Nuclear option:

git rebase --abort
git reset --hard origin/main

Then start the rebase again. Just make sure you don't have uncommitted work you care about before reset --hard.

Invalid Command in the Rebase Todo

Classic mistake — you accidentally typed your vim quit command into the todo file. Open the file manually and clean it up:

nano .git/rebase-merge/git-rebase-todo

Remove the weird lines, save, and:

git rebase --continue

"Everything up-to-date" on Push

If your push says there's nothing to push, the rebase probably didn't actually finish. Check git status, finish whatever step Git is waiting on, and try pushing again.

Verify Your Work

Once everything's pushed, check the log:

git log -2

You should see the correct author name and email on the commits you fixed. If not, something went sideways in the rebase — don't push further, just investigate.

Lessons I Took Away

• Set your repo-level Git config before your first commit. It's thirty seconds of prevention that saves an hour of cleanup.
• Interactive rebase is honestly not scary once you've done it a couple of times. It's just a todo list for Git.
• Never start a new rebase when one is already in progress. Finish or abort the old one first.
• Force pushes are fine on your own branches. Think twice on shared ones.

Wrapping Up

Rewriting Git history sounds intimidating the first time you do it, but it's really just following a short checklist. The tools are all there — you just need to trust the process and not panic when something errors out.

If you're hitting this problem for the first time, take a breath, work through it step by step, and you'll be fine. And maybe set that --local config right after cloning next time.

🪦 Teacher's closing remark

See? Clean. No leaks. No drama. No corporate espionage vibes.