GitFixing Commits on Wrong Branch

I Committed to the Wrong Branch

You finish a feature, type git commit, and then realise you were on main instead of your feature-x branch. This is one of the most common Git mistakes. The good news is that commits are just objects — you can move them around. This page covers every scenario from a simple local mistake to an already-pushed commit.

Understand the situation first

Check where you are and what you committed

Bash
git log --oneline -5
# abc1234 (HEAD -> main) Add user authentication   ← this should be on feature-x
# def5678 Merge pull request #12
# ghi9012 Update README

git branch
# * main
#   feature-x
Scenario A: The commit is local (not yet pushed)

This is the easiest case. The commit only exists on your machine. The plan is:

  1. Create (or identify) the target branch so it points at the wrong commit.

  2. Undo the commit from main with a soft reset (keeps your changes staged).

  3. Switch to the feature branch.

  4. Commit your staged changes there.

Method 1: branch + soft reset (recommended)

Bash
# Step 1: create feature-x pointing at the current commit
#         (skip this if feature-x already exists — we'll cherry-pick instead)
git branch feature-x
# feature-x is now pointing at abc1234

# Step 2: undo the commit from main, but keep the changes staged
git reset HEAD~1 --soft
# HEAD is now at def5678
# Your file changes are staged and ready

# Step 3: switch to the feature branch
git switch feature-x

# Step 4: commit
git commit -m "Add user authentication"
# Done — the commit lives only on feature-x
--soft vs --mixed vs --hard
`--soft` keeps changes staged. `--mixed` (default) keeps changes unstaged. `--hard` discards changes entirely. For this workflow always use `--soft`.
Scenario B: feature-x already exists with other commits

If feature-x already exists and has its own history, use git cherry-pick to copy the commit, then reset it from main.

Method 2: cherry-pick + reset

Bash
# Note the hash of the commit you made by mistake
git log --oneline -3
# abc1234 (HEAD -> main) Add user authentication   ← wrong branch
# def5678 Merge pull request #12

# Step 1: switch to the correct branch
git switch feature-x

# Step 2: copy the commit here
git cherry-pick abc1234
# [feature-x xyz9999] Add user authentication
# The commit is now on feature-x

# Step 3: go back to main and remove the wrong commit
git switch main
git reset HEAD~1 --hard
# HEAD is now at def5678
# (safe here because feature-x already has the commit)
Warning
`git reset --hard` permanently discards anything not committed or stashed. Only use it after you have confirmed the commit is safely on the feature branch.
Scenario C: Multiple commits on the wrong branch

Moving several commits

Bash
git log --oneline -6
# abc1234 (HEAD -> main) Add logout endpoint
# bcd2345 Add login endpoint
# cde3456 Add auth middleware       ← these three belong on feature-auth
# def4567 Merge PR #11 (correct base)

# Step 1: create the feature branch at the current position
git branch feature-auth

# Step 2: reset main back to the correct base commit
git reset def4567 --soft
# All three commits' changes are now staged

# Step 3: switch to the feature branch
git switch feature-auth

# Step 4: commit (or leave as individual commits if you prefer)
git commit -m "Add authentication feature"
Tip
If you want to keep the three commits as separate commits on `feature-auth`, use `git reset def4567 --soft` then commit each group of files individually, or use `git cherry-pick cde3456^..abc1234` on the feature branch before resetting main.
Scenario D: The commit has already been pushed
Warning
Once you push to a shared branch like `main`, others may have already pulled your commit. Rewriting history with `git reset` + `git push --force` will cause serious problems for your teammates. Read this section carefully before proceeding.

If the commit was pushed to a protected or shared branch, the safest approach is to NOT rewrite history. Instead:

  1. Cherry-pick the commit to the correct feature branch.

  2. Create a new commit on main that reverts the accidental commit.

  3. Push both.

Safe fix for pushed commits

Bash
# Step 1: switch to the feature branch and cherry-pick
git switch feature-x
git cherry-pick abc1234
git push origin feature-x

# Step 2: back on main, revert the accidental commit
git switch main
git revert abc1234 --no-edit
# Creates a new commit: "Revert 'Add user authentication'"

# Step 3: push the revert
git push origin main
# No force-push needed. History is additive, not rewritten.
Force-push approach (solo or pre-review branches only)

If you are the only person using the branch (a feature branch, not main), and you know nobody has pulled it, you can use force-push to clean up history:

Force-push approach — solo branches only

Bash
# Ensure the commit is on feature-x first
git switch feature-x
git cherry-pick abc1234
git push origin feature-x

# Now rewrite main locally and force-push
git switch main
git reset abc1234^ --hard   # reset to parent of the bad commit
git push --force-with-lease origin main
Warning
Never force-push `main` if others have already pulled it. Teammates will get diverged history and face a confusing situation when they try to push. Coordinate with your team before any force-push to a shared branch, and prefer the `git revert` approach instead.
Prevention: use branch protection

  • Enable branch protection on main in GitHub/GitLab — direct pushes require a PR.

  • Set git config branch.main.pushRemote no_push to block accidental pushes to main from your machine.

  • Use a shell prompt that always shows your current branch name.

  • Develop the habit of running git branch or git status before committing.