Chapter 2.4 — Committed to Wrong Branch☕ 16 min read

Committed to Wrong Branch

Galat branch pe commit? Daro mat — soft reset se undo karo, sahi branch pe redo karo.

01The Most Common Git Mistake

The scenario: You are on main, make changes, commit them, and then realize — this should have been on a feature branch. Sound familiar? This is the most common "Oh shit" moment in Git.

If you have NOT pushed: easy fix. Use git reset --soft HEAD~1 to undo the commit while keeping your changes staged.

If you have already pushed: harder fix. You must use git revert to create an "anti-commit" on the wrong branch, then git cherry-pick to copy the commit to the right branch.

The key tool for unpushed fixes: git reset --soft HEAD~1.

--soft moves the branch pointer back but keeps your changes in the staging area, ready to commit again. Nothing is lost.

# The disaster: committed on main instead of feature
git branch
# * main     ← Oops! Should be on feature branch

echo "new feature code" > feature.js
git add feature.js
git commit -m "feat: add new feature"

# Realized you are on main! Do not panic.

The golden rule: If you have NOT pushed, git reset --soft is your best friend. It undoes the commit but keeps all your work. If you HAVE pushed, you must use git revert instead — never force push to shared branches.

02Fix with Soft Reset + Stash

Step 1: git reset --soft HEAD~1 — Undo the last commit, but keep all changes staged.

Step 2: git stash — Temporarily save the staged changes. This is the safest method to transport changes between branches.

Step 3: git checkout -b feature — Create and switch to the correct branch.

Step 4: git stash pop — Bring your changes back.

Step 5: git commit -m "feat: add new feature" — Commit on the right branch.

Alternative to stash: After soft reset, just switch branches. If your changes do not conflict with the target branch, they travel with you to the new branch. But stash is safer — no surprises.

# Step 1: Undo the commit, keep changes staged
git reset --soft HEAD~1
git status
# Changes to be committed:
#   new file:   feature.js

# Step 2: Stash the changes (safest approach)
git stash

# Step 3: Create and switch to the correct branch
git checkout -b feature/new-feature

# Step 4: Pop the stash
git stash pop

# Step 5: Commit on the correct branch
git commit -m "feat: add new feature"

# Verify: main is clean, feature has the commit
git log --oneline main       # no feature commit
git log --oneline feature/new-feature  # has the feature commit

💡 Pro Tip: After git reset --soft HEAD~1, your changes are in the staging area. You can also skip the stash and directly git checkout -b feature — the staged changes will follow you. But if anything goes wrong during the switch, stash is your safety net.

03Fix with Cherry-pick

If you already pushed the commit to the wrong branch, or prefer a different workflow, use git cherry-pick.

Cherry-pick copies a commit from one branch to another. The original commit stays where it is.

Step 1: Copy the hash of the wrong commit.

Step 2: Switch to the correct branch.

Step 3: git cherry-pick <hash> — Apply the commit here.

Step 4: Switch back to the wrong branch and git revert <hash> to remove it.

This is the safest method if the commit has already been pushed.

# You committed on main (and maybe even pushed)
git log --oneline -1
# a1b2c3d feat: add new feature

# Step 1: Note the hash
HASH=$(git rev-parse HEAD)

# Step 2: Switch to the correct branch
git checkout -b feature/new-feature

# Step 3: Cherry-pick the commit
git cherry-pick $HASH
# The commit is now on feature branch too!

# Step 4: Remove it from main
git checkout main
git revert $HASH
# Creates an "anti-commit" that undoes the changes on main
git push origin main

# Verify
git log --oneline main   # has the revert
git log --oneline feature/new-feature  # has the original commit

Cherry-pick creates a COPY, not a move. The original commit still exists on main. That is why you must also git revert the original on main. If you only cherry-pick without reverting, both branches have the same changes — which is not what you want.

04The Pushed Commit Problem

If the commit is already pushed to a shared branch (main, develop), you CANNOT use reset.

Using git reset on a pushed branch would require a force push, which overwrites team history. Your teammates would have broken repositories.

Instead, use git revert <hash> to create a new commit that undoes the changes. Then cherry-pick the original commit to the correct branch.

This preserves the history: anyone looking at the log sees the commit + revert, which is transparent and honest.

The only downside: your git log has a "revert" commit, which is a small price for safety.

# ALREADY PUSHED TO MAIN - DO NOT RESET!
# Bad: git reset --hard HEAD~1 && git push --force  (destroys team history)

# Good: Revert + Cherry-pick
# 1. Get the hash
git log --oneline -1  # abc1234 feat: new feature

# 2. Revert on main (undo the changes)
git revert abc1234
git push origin main

# 3. Cherry-pick to correct branch
git checkout -b feature/new-feature
git cherry-pick abc1234
git push -u origin feature/new-feature

05Prevention — Check Before You Commit

The best fix is prevention. Always check git branch or your prompt before committing.

Configure your terminal prompt to show the current branch name — this one habit prevents 90% of wrong-branch commits.

Use git status before every commit — it shows the current branch at the top.

Some teams use pre-commit hooks to warn if you are committing directly to main.

You can also set init.defaultBranch to something other than main if you frequently accidentally commit there.

# Prevention 1: Check before you commit
git branch           # am I on the right branch?
git status           # shows current branch at top

# Prevention 2: Show branch in terminal prompt
# Add to ~/.bashrc or ~/.zshrc:
# parse_git_branch() {
#   git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/ (\1)/'
# }
# PS1="\w\$(parse_git_branch) $ "

# Prevention 3: Warn before committing to main
# Add to .git/hooks/pre-commit:
# BRANCH=$(git rev-parse --abbrev-ref HEAD)
# if [ "$BRANCH" = "main" ]; then
#   echo "WARNING: You are committing to main!"
#   read -p "Continue? (y/n) " -n 1 -r
#   if [[ ! $REPLY =~ ^[Yy]$ ]]; then exit 1; fi
# fi

💡 Pro Tip: The easiest prevention: make your terminal show the branch name. Most modern terminals (Oh My Zsh, Starship, Powerlevel10k) do this by default. If your prompt does not show the branch, you are flying blind. Fix it today — it takes 5 minutes and saves hours of "wrong branch" headaches.

Lo kar liya — Key Points:

✅ If you commit to the wrong branch and haven't pushed: use git reset --soft HEAD~1 to undo the commit while keeping changes staged
✅ After soft reset, stash the changes, switch to the correct branch, pop the stash, and commit
✅ If the commit is already pushed: use git cherry-pick <hash> to copy it to the right branch, then git revert <hash> on the wrong branch
✅ Never use git reset on a pushed, shared branch — it requires force push and destroys team history
✅ git cherry-pick copies a specific commit from one branch to another, creating a new commit with a new hash
✅ Prevent wrong-branch commits by always checking git branch or git status before committing

Previous2.3 — Fix Commit Message — amend rewrite 📋 All Chapters Next Chapter2.5 — Undo Old Commits — revert vs reset →