Introduction

When you try to switch branches with uncommitted changes, Git either carries the changes to the new branch (if there are no conflicts) or refuses to switch to protect your work. The three main strategies for handling this are: git stash (temporarily shelve changes), committing to the current branch (even as a WIP commit), or using git checkout --merge to attempt a merge. Understanding when Git allows the switch and when it blocks is key to a smooth workflow.

When Git Allows the Switch

1# Git allows switching if uncommitted changes don't conflict
2# with the target branch
3
4# Example: you modified file_a.txt on branch "feature"
5git checkout main
6# Success — file_a.txt changes carry over to "main"
7# because file_a.txt is the same on both branches
8
9# Git BLOCKS switching when there's a conflict
10# Example: file_a.txt differs between branches and you have local edits
11git checkout main
12# error: Your local changes to the following files would be overwritten
13# by checkout:
14#     file_a.txt
15# Please commit your changes or stash them before you switch branches.

Git checks whether your uncommitted changes would be overwritten by the branch switch. If the files you modified are identical on both branches, the switch succeeds and your changes travel with you. If the files differ, Git refuses to avoid losing your work.

Strategy 1: Git Stash

1# Save uncommitted changes to the stash
2git stash
3
4# Now switch branches freely
5git checkout main
6
7# Do your work on main...
8git commit -m "Fix bug on main"
9
10# Switch back and restore your changes
11git checkout feature
12git stash pop
13
14# List all stashes
15git stash list
16# stash@{0}: WIP on feature: abc1234 Last commit message
17
18# Stash with a descriptive message
19git stash push -m "halfway through login form"
20
21# Apply a specific stash without removing it
22git stash apply stash@{1}

git stash saves both staged and unstaged changes to a stack and reverts the working directory to the last commit. git stash pop restores the changes and removes the stash entry. Use git stash apply to restore without removing.

Strategy 2: WIP Commit

1# Commit your in-progress work
2git add -A
3git commit -m "WIP: login form validation"
4
5# Switch branches
6git checkout main
7
8# Do work on main...
9
10# Switch back and undo the WIP commit
11git checkout feature
12git reset --soft HEAD~1
13# Changes are back as staged (uncommitted) changes
14
15# Or use --mixed to unstage them too
16git reset HEAD~1
17# Changes are back as unstaged modifications

A WIP commit is a normal commit you plan to undo later. git reset --soft HEAD~1 moves the branch pointer back one commit but keeps all changes staged. This approach is cleaner than stash when you want the changes visible in the log temporarily.

Strategy 3: Git Worktree

1# Create a separate working directory for another branch
2git worktree add ../main-hotfix main
3
4# Now you have two directories:
5# ./my-project/          — on "feature" branch (unchanged)
6# ./main-hotfix/         — on "main" branch (separate checkout)
7
8# Work in the hotfix directory
9cd ../main-hotfix
10# make changes, commit, push...
11
12# Remove the worktree when done
13cd ../my-project
14git worktree remove ../main-hotfix

git worktree lets you check out multiple branches simultaneously in different directories. No stashing or committing needed — your feature branch stays untouched while you work on main in a separate folder.

Strategy 4: Checkout with Merge

1# Force Git to attempt a three-way merge of your changes
2git checkout --merge main
3
4# If the merge succeeds, your changes are applied on top of main
5# If there are conflicts, Git marks them in the files:
6# <<<<<<< yours
7# your changes
8# =======
9# main's version
10# >>>>>>> main
11
12# Resolve conflicts and continue

--merge attempts to apply your uncommitted changes on the target branch using a merge strategy. This is useful when you started working on the wrong branch and want to move your changes to the correct one.

Moving Uncommitted Changes to a New Branch

1# You started work on main but should be on a feature branch
2# Your uncommitted changes are still in the working directory
3
4# Create and switch to a new branch (changes come with you)
5git checkout -b new-feature
6
7# Or with git switch (Git 2.23+)
8git switch -c new-feature
9
10# Now commit on the new branch
11git add -A
12git commit -m "Add login form"

Creating a new branch from the current HEAD always succeeds because the new branch starts at the same commit — there are no conflicting file differences.

Common Pitfalls

• Assuming stash is a safe long-term storage: git stash entries can be accidentally dropped with git stash drop or git stash clear. Stashes are not pushed to remotes. For work you want to preserve, commit it to a branch instead of relying on the stash stack.
• Using git checkout -f to force switch: git checkout -f main discards all uncommitted changes permanently. This is irreversible — there is no way to recover unstaged changes after a force checkout. Only use -f when you intentionally want to discard your work.
• Forgetting to stash pop after switching back: Stashed changes sit in the stash stack until explicitly applied. Developers often stash, switch branches, finish their work, and forget to restore the stash. Use git stash list regularly to check for forgotten stashes.
• Stashing only staged changes unintentionally: git stash saves both staged and unstaged changes by default. However, git stash --keep-index only stashes unstaged changes, which can be confusing. Know which variant you are using to avoid partial stashes.
• Not understanding when changes carry over between branches: If you modify a file that is identical on both branches, git checkout silently carries your changes to the new branch. This can be surprising — you may accidentally commit changes to the wrong branch if you do not check git status after switching.

Summary

• Git allows branch switching with uncommitted changes if there are no file conflicts
• Use git stash to temporarily shelve changes, then git stash pop to restore
• Use a WIP commit + git reset --soft HEAD~1 for a more explicit approach
• Use git worktree to work on multiple branches simultaneously without stashing
• git checkout -b new-branch always succeeds and carries uncommitted changes
• Never use git checkout -f unless you intentionally want to discard all uncommitted work