Move uncommitted changes from main to a new Git branch

If you started editing on main or master and want a new branch at the same current commit, run git switch -c <new-branch>. The staged and working-tree changes remain available, and your next commit advances the new branch.

Create the branch and commit the intended work

git status
git switch -c feature/should-have-been-here
git diff
git diff --staged

The older branch-creation command is git checkout -b feature/should-have-been-here. You do not need a stash merely to create a new branch at the existing HEAD.

Stage the files or hunks that belong in this change, then inspect the complete staged snapshot and commit:

git add -p
git diff --staged
git commit -m "Add request validation"

Use an explicit git add -- path/to/new-file for new files, or git add -A if every eligible change should be included. Existing staged changes are included by a normal commit too. The original branch pointer stays at its earlier commit; unrelated edits can remain in your working tree.

Use a stash when the starting point must change

Switching to a different commit can be refused if it would overwrite local edits. For example, if the new feature must start at develop instead of the current main, preserve the work first:

git stash push -u -m "Move work to develop-based feature"
git switch -c feature/new develop
git stash apply --index 'stash@{0}'

Inspect the result before dropping the saved entry. -u includes untracked files but excludes ignored files. --index asks Git to restore the staged state as well; that restoration or the patch application can conflict on a different base. Confirm that stash@{0} still identifies this saved entry if you performed other stash operations.

After checking the restored work and completing any required commit, remove the specific stash entry you no longer need:

git stash drop 'stash@{0}'

Using apply keeps the entry while you verify the result. If you use pop instead and it conflicts, the entry remains. Resolve the conflicted files, stage the resolutions, and remove the retained entry only after checking that your work is safe.

What if the work was already committed on main?

First preserve the current tip under the intended feature branch:

git switch -c feature/oops

For unshared local commits, inspect the history to identify the exact commit where main should point. While checked out on feature/oops, you can move the local branch reference without resetting the working tree:

# Replace a1b2c3d with the verified previous tip of main.
git branch -f main a1b2c3d

This changes local history on main; it is appropriate only when the retained feature branch contains the work and the chosen target is correct. Git refuses if main is checked out in another worktree. Use master instead when that is the branch name. Do not assume an old origin/main reference is the right target.

If the commits were already shared, coordinate the correction. A revert on main may be appropriate; avoid silently rewriting the branch and force-pushing over collaborators’ work.

Can I move only some changes?

Creating a branch does not partition uncommitted work by branch. One approach is to commit only the relevant hunks on the new branch and keep the remaining edits unstaged. Switching back may carry those remaining edits or be refused if they would be overwritten.

git stash -p can save selected hunks, but it is a selection tool, not an automatic branch assignment. Check git diff and git diff --staged before and after each step so you know which changes are in the commit, stash, and working tree.

References

• git-switch
• git-checkout
• git-stash
• git-branch
• git-add