Knowledge Base
Software
2025-10-17
6 min

Moving Uncommitted Git Changes Between Branches

A concise, battle-tested guide for safely moving uncommitted changes from one Git branch to another - without committing or losing work. Explains stashing, switching, popping, verifying clean states, and handling conflicts, plus advanced alternatives like cherry-picking, patch files, and worktrees.

Git
Branching
Stash
Cherry-pick
Workflows
DevOps

You made edits on the wrong branch and only ran git add .? No worries. The safest, cleanest way is to stash those uncommitted changes on the current branch and then pop them onto the correct branch.

This entry documents a robust workflow to move your staged/unstaged/untracked edits from release/staging to release/dev without leaving any drift behind.

โšกFast Path

  1. 1
    Confirm you are on the wrong branch
    git branch --show-current
  2. 2
    Stash everything (incl. untracked)
    git stash push -u -m "WIP: move from release/staging to release/dev"
  3. 3
    Switch to the correct branch
    git switch release/dev
  4. 4
    Update the branch (optional, recommended)
    git pull --ff-only
  5. 5
    Apply the work here
    git stash pop
  6. 6
    Resolve conflicts, stage, commit, push
    git add -A && git commit -m "Describe changes" && git push origin release/dev
  7. 7
    Verify the original branch is clean
    git switch release/staging && git status
โ„น๏ธ
Stashing preserves your index (staged set) and working tree. pop re-applies both. If conflicts occur, Git keeps the stash so you can retry after resolving.

๐Ÿ›ŸThe Safe Way - With Commands

move-changes.sh
# 1) On the wrong branch (e.g., release/staging)
git status
git branch --show-current   # should print: release/staging

# 2) Stash EVERYTHING (staged, unstaged, untracked)
git stash push -u -m "WIP: move from release/staging to release/dev"

# 3) Switch to the correct branch (e.g., release/dev)
git switch release/dev      # or: git checkout release/dev

# 4) Make sure it's up to date
git pull --ff-only          # fast-forward only keeps history tidy

# 5) Re-apply your work here
git stash pop               # applies most recent stash and drops it on success

# 6) If there are conflicts, resolve them, then:
#    git add <resolved files>
#    git commit -m "Describe the changes"

# 7) Push
#    git push origin release/dev

# 8) (Optional) Confirm the stash is gone (pop auto-drops on success)
git stash list

If pop failed due to conflicts, Git leaves the stash in place so you can retry later. After a successful apply + commit, you can manually drop any leftover stash with git stash drop stash@{0}.

๐Ÿ”Verify the Source Branch is Unchanged

verify-clean.sh
git switch release/staging
git status

# Belt-and-braces: hard sync local with remote once you're happy
# (Only do this if you're certain โ€” it discards local changes!)
git fetch origin
git reset --hard origin/release/staging
โš ๏ธ
Use reset --hard only after you've confirmed your changes are safely committed on the target branch and you truly want no local divergence on the source branch.

๐ŸงญAlternatives (When Stashing Isn't Ideal)

  • Temporary commit + cherry-pick - If you prefer not to stash, make a temporary commit on the wrong branch, switch to the right branch, git cherry-pick <temp-commit-sha>, then reset the wrong branch back to origin.
  • Patch file route -git diff > move.patch, then on the target branch git apply move.patch. Good for reviewable diffs, but loses index (staged) state.
  • Worktree approach - Use git worktree add ../repo-dev release/dev to have both branches checked out simultaneously, then copy/apply changes safely between trees.

๐ŸงจEdge Cases & Gotchas

  • Untracked files: Include them with -u in git stash push -u; otherwise they won't move.
  • Submodules: Stash doesn't recurse into submodules automatically. Commit inside submodules or handle them separately.
  • Binary conflicts: Expect manual resolution; stash won't magically merge binaries.
  • Index state: Stash preserves what was staged. After pop, your index may include staged files already.
  • Pop vs. Apply: pop applies then drops on success. Prefer apply if you want to keep the stash around while testing.
  • Safety reset: If you accidentally mutated the wrong branch, git reset --hard origin/<branch> will restore it.

โ“FAQ Snippets

faq.sh
# See what's in your stash stack
git stash list

# Show the diff inside a stash entry
git stash show -p stash@{0}

# Apply without dropping the stash (safer while testing)
git stash apply stash@{0}

# Keep index as-is, stash only unstaged changes
git stash push --keep-index -m "stash only unstaged"

# Unstage everything if you want a clean index before stashing
git restore --staged :/

๐Ÿš€Summary

Use git stash to lift your in-flight edits off the wrong branch, move to the right branch, and re-apply them safely. Confirm the source branch is pristine, then commit and push from the target. This keeps history clean and prevents accidental drift.

Filed under: Git, Branching, Stash, DevOps, Workflows

Last updated: 2025-10-17