A walkthrough of the Committed to Wrong Branch tutorial: how to move a commit off main and onto a feature branch using git branch and git reset, without losing the work.
This scenario is the classic "oops, that went on main" moment. You committed a feature directly to main when it should have been on its own branch. The fix keeps the commit intact while moving main back to where it belongs.
The situation
This commit ended up on the wrong branch. The goal is to move it to the right one.
main has two commits: the Initial commit, and Add skills section, which added a skills section to index.html. That second commit was meant for a feature branch, not for main directly.
Nothing is broken, but main now carries unfinished feature work. The goal is to take that latest commit off main and put it on a feature branch, so main goes back to a clean state.
Start with git log --oneline. Seeing Add skills section as the latest commit on main confirms exactly what you need to move.
The fix, step by step
git branch feature captures the commit on a new branch.
Confirm what is on main
git log
The log shows Add skills section sitting on top of main. That is the commit to relocate.
Save the commit on a new branch
git branch feature/skills
This creates a branch pointer at the current commit. The Add skills section work is now safely recorded on feature/skills, even though you are still on main.
Move main back one commit
git reset --hard HEAD~1
This rewinds main to before the skills commit. Because the commit is already saved on feature/skills, nothing is lost: only main's pointer moves.
Switch to the feature branch to continue
git checkout feature/skills
Now main is clean and the skills work lives on its own branch, ready to keep developing or open a pull request.
Why the order matters
The safety of this fix depends entirely on creating the branch before resetting:
git branch feature/skills saves the commit.
git reset --hard HEAD~1 then only moves main.
If you run git reset --hard first without creating the branch, main moves back and the commit is no longer on any branch. It is usually still recoverable with git reflog, but branching first avoids the scare entirely.
reset --hard rewrites history. It is safe here because main has not been pushed. On a shared main, undo with git revert instead.
Moving commits between branches: the common recipes
cherry-pick copies the commit onto the target branch: same change, a new hash.
The fix depends on where the commit needs to go and whether it has been pushed:
- Committed to
main, want it on a new branch (local only) — git branch feature, then git reset --hard HEAD~1 on main. The commit now lives on feature.
- Move it onto an existing branch —
git checkout target, git cherry-pick <commit>, then delete it from the source with git reset --hard.
- Move several commits — branch first to keep them all, then
git reset --hard HEAD~N; or cherry-pick a specific range onto the target.
- The commit was already pushed — do not rewrite public history. Undo it on the shared branch with
git revert and re-apply the work on a feature branch.
Practise the local case in the terminal here until the "branch, then reset" reflex is automatic; it is the one you will reach for most.