Committed to the wrong branch? Move the commit
These blocks describe different cases, not one script. Choose the case that matches your repository. Replace example branch names, file paths and VERIFIED_COMMIT before use. Abort commands apply only to their active operation; do not run both alternatives.
Short answer
If you committed to the wrong branch, first give the existing commit a rescue branch. Apply its change to the intended branch with cherry-pick and inspect the result. Only then remove it from the original branch: reset can suit a private tip; a shared branch normally needs a revert. Move the change first, then choose how to correct the original branch.
The example and its prerequisites
This example starts with one case: one ordinary, non-merge commit at the tip of main, which belongs on an existing feature/fix branch. The working tree is clean. Replace these example branch names with your own. If several commits, a merge, or unrelated work followed the mistake, stop and identify the precise range rather than copying the final reset below.
Inspect before changing anything
Read status, the current branch and the recent graph before changing anything. Check the commit's files and patch, not just its subject. A commit can contain work from several people or tasks. Record its full object ID as SCHOOL_MISTAKE; this names the original commit even after switching branches. Check whether colleagues already have it before choosing how to repair main.
git status --short
git branch --show-current
git log -5 --oneline --decorate
git show --stat HEAD
SCHOOL_MISTAKE=$(git rev-parse HEAD)Keep a reference or a separate checkout
A rescue branch keeps the committed object reachable while you work. It does not copy uncommitted edits. If status shows local changes, save and verify those separately before the example: a deliberate commit, a reviewed stash, or an external copy can be appropriate. A stash with -u includes untracked files, but not ignored files. Do not assume reflog contains any of those unsaved file contents.
git branch rescue/wrong-branch "$SCHOOL_MISTAKE"
git show --stat rescue/wrong-branchThe first workflow
Switch to the intended branch and cherry-pick the saved object ID. Git applies that commit's change and usually creates a new commit with a different ID. That is expected: its parent has changed. Inspect the new patch and run the project's relevant checks. Do not reset the original branch until the destination contains the change you actually wanted and you have a recoverable reference to the original.
git switch feature/fix
git cherry-pick "$SCHOOL_MISTAKE"
git show --stat HEADChoose the other outcome deliberately
For the private-tip case only, return to main and confirm its HEAD still equals SCHOOL_MISTAKE. With a clean working tree and the rescue branch preserved, reset to the mistake's parent removes that commit from main. The hard reset also replaces tracked working-tree content, so the clean-tree condition matters. If main moved, or the commit was shared, this exact command sequence no longer fits.
git switch main
git status --short
git rev-parse HEAD
git reset --hard "${SCHOOL_MISTAKE}^"Limits and exceptions
When the mistake reached a shared branch, prefer an ordinary revert on that branch. It adds a new commit reversing the selected change without removing other people's history. The destination cherry-pick and the original revert have separate outcomes; review both. Coordinate with collaborators when the wrong commit has already been merged elsewhere. Do not turn this guide into an automatic force-push recipe.
git switch main
git revert "$SCHOOL_MISTAKE"Conflicts and cleanup
Cherry-pick can stop with conflicts. Read git status, resolve only the intended files, stage them and continue; use cherry-pick --abort if the chosen change or destination was wrong. Revert has its own continue and abort commands. An abort exits the active operation; it is not a general backup for edits made outside it. Avoid starting a second repair while Git reports an unfinished operation.
git status
git cherry-pick --abortgit revert --abortVerify the result
The final graph should show the intended change on feature/fix and the chosen correction on main. Compare both patches and inspect status in each checkout. Keep rescue/wrong-branch until the repair is reviewed; delete it later only when you no longer need that reference. A clean status alone does not prove the application still behaves correctly.
git log -6 --oneline --decorate --all
git show --stat feature/fix
git status --shortCommon questions
Can I move several commits? Yes, but first identify their order, dependencies and exact range. Can I use reset --soft instead? It moves the branch while keeping the index and worktree; it does not transfer a commit to another branch by itself. What if I already pushed? Start with the shared-history revert case and coordinate any exceptional rewrite explicitly.
Review the operation in FluxGit
Use FluxGit’s visual history and patch view to review the operation and the relevant commits. Keep the branch, sharing and local-file checks in this example. The download page lists the currently available builds and platforms.