Advanced Scenarios: Managing a Multi-Branch Workflow

You're deep in a feature branch with ten modified files when your manager says "urgent bug on main." You can't commit half-finished work, and you can't lose it either. The stash is your escape hatch.

The stash is a temporary, private holding area for your dirty changes.

# 1. Stash your changes (-u includes brand-new files)
git stash push -u -m "WIP: refactoring pipeline, AI changes"

# 2. Fix the urgent bug
git switch main
git pull
git switch -c hotfix/urgent-bug
# ... fix, test, commit, push, create PR ...

# 3. Return to your work
git switch feature/A
git stash pop

git stash pop re-applies your changes and removes them from the stash. Use git stash apply to keep the stash entry for reuse.

In VS Code, you can do all of this without memorizing commands. Open the ... menu in the Source Control panel -- you'll see a Stash submenu with all the options you need:

VS Code Expand

Choose "Stash (Include Untracked)" to save all your work. When you're ready to come back, go to ... → Stash → "Pop Latest Stash" to restore everything exactly where you left off.

Try It: The Stash Workflow

Your feature branch has been alive for a few days and main has moved on without you. Now you need to catch up — and Git offers two philosophies with very different trade-offs.

You have two options for catching up with main, and each tells a different story in your commit history.

VS Code supports both approaches. Use the ... menu in Source Control → "Pull (Rebase)" to rebase instead of merge when pulling. For merging, use the Command Palette (Cmd+Shift+P / Ctrl+Shift+P) → "Git: Merge Branch..." and select the branch to merge.

One config gem while you're here: git config --global rebase.autostash true makes Git stash your uncommitted work automatically before a rebase (or pull --rebase) and pop it after — dissolving the "Git blocked my switch" problem 5.1 opened with, for the rebase case at least.

Try It: Merge vs. Rebase

Rebase has one more trick: git rebase -i (interactive) lets you rewrite your own branch's history commit by commit — squash five "wip" commits into one, reword a sloppy message, drop an experiment entirely. It's how a messy working branch becomes a clean, reviewable PR. The Golden Rule applies double here: only ever on commits that haven't been shared.

Try It: Squash the WIP

This is the moment every developer dreads the first time — and handles calmly by the tenth. Two people changed the same lines, and Git needs a human to decide which version wins.

Don't panic -- conflicts look intimidating at first, but they follow a simple pattern. Git inserts special markers into your file to show you exactly where the disagreement is.

The Conflict Markers

<<<<<<< HEAD
x = 10
# AI refactor
=======
x = 5
# teammate fix
>>>>>>> main

Everything between <<<<<<< HEAD and the ======= divider is your side (here, the AI's refactor on your branch). Everything below the divider is the incoming side — the label after >>>>>>> names where it came from — the branch you merged (like main here; after a pull it can be a commit id or a longer label instead).

Delete all the markers (<<<, ===, >>>) and edit the code to be the correct final version, then stage and commit. In the playground, you can write the resolved file with echo 'x = 10' > src/model.py.

Not ready to deal with it? There's an eject button here too: git merge --abort cancels the merge and returns your branch to exactly how it was before you ran git merge — the same guilt-free escape you'll meet again with rebase (5.5) and cherry-pick (5.4).

The VS Code Way (The Superior Way)

Editing conflict markers by hand works, but VS Code makes the whole process much more visual and less error-prone.

VS Code Expand

For complex conflicts with multiple overlapping changes, click "Resolve in Merge Editor" to open the full 3-way view. This gives you the most control over the final result:

VS Code Expand

Try It: Resolving a Merge Conflict

Your AI experiment branch is a mess — half-finished rewrites, abandoned TODOs, dead ends. But buried in the middle is one brilliant commit: a currency rounding fix that actually works. You don't want the branch. You want that one commit.

git cherry-pick copies one commit's changes onto your current branch as a new commit — same change, same message, but a brand-new hash, because it now sits on a different parent. The original commit stays untouched on its branch.

git log --oneline --all      # Find the gem's hash on the experiment branch
git switch main              # Stand on the branch that should receive it
git cherry-pick e4f5a6b      # Copy exactly that commit here
git log --oneline            # The fix is on main — the junk is not

For an audit trail, add -x: it appends "(cherry picked from commit e4f5a6b...)" to the message, so anyone reading main later can trace where the fix came from. Perfect for the reject-the-PR workflow below.

When to prefer it over merging: merge when the whole branch is worth keeping; cherry-pick when only part of it is. And because a cherry-picked commit replays changes onto code that may have moved on, conflicts can happen here too — the escape hatches mirror rebase exactly:

# Fix the conflicted file, then:
git add <file>
git cherry-pick --continue

# Or walk away as if nothing happened:
git cherry-pick --abort

Try It: Cherry-Pick the Gem

Section 5.2 sold you on rebase for clean history — but it skipped the scary part. Your feature branch tuned src/config.py, main changed the same lines, and halfway through the rebase Git slams the brakes. Here's how to read the wreck and drive out of it.

Remember what rebase does: it replays your commits one at a time on top of the latest main. If a replayed commit touches lines that main also changed, Git can't guess the winner — so it pauses mid-replay and hands you the keys. Run git status to see the paused state: it reports a rebase in progress and lists the conflicted files under "unmerged paths". The files contain the conflict markers you learned to read in section 5.3 — with one crucial twist.

<<<<<<< HEAD
TIMEOUT = 10     # main's version (HEAD during a rebase!)
=======
TIMEOUT = 120    # your commit, being replayed
>>>>>>> a1b2c3d (feat: raise the worker timeout)

From here, it's a three-step ritual — the same one every time:

# 1. Fix the file — remove the markers, keep the right code
echo 'TIMEOUT = 120' > src/config.py

# 2. Tell Git the conflict is resolved
git add src/config.py

# 3. Resume the replay
git rebase --continue

If more commits remain, Git keeps replaying — and may pause again on the next conflict. Just repeat the ritual until the rebase completes. And if at any point you're lost, confused, or late for dinner, there's a guilt-free eject button:

git rebase --abort   # Everything returns EXACTLY as it was before the rebase

Try It: Survive a Rebase Conflict

Branches move — every commit drags them forward. But some moments deserve a permanent name: the commit you shipped, the version that passed the audit, the last known-good state before a big AI refactor. That's what tags are: labels that stick to one commit, forever.

Git has two kinds of tags, and the choice matters more than it looks:

Naming convention: most projects use semantic versioning — MAJOR.MINOR.PATCH. Bump MAJOR when you break existing users (v1.x → v2.0.0), MINOR when you add features compatibly (v1.0 → v1.1.0), and PATCH for pure bug fixes (v1.1.0 → v1.1.1). One glance at a version tells users how scared to be.

git tag -a v1.1.0 -m "Release: import support"   # Tag HEAD
git tag                                          # List all tags
git log --oneline                                # Tags appear as decorations
git show v1.0.0                                  # Inspect what a release points at

One surprise: in real Git, git push does not send tags. You push them explicitly — git push origin v1.1.0 for one tag, or git push origin --tags for all of them — though beware: --tags throws every tag at the remote, including private bookmarks like the pre-refactor checkpoint below. git push --follow-tags is the discerning version: it sends only annotated tags on commits you're pushing — which is exactly why this section told you to annotate releases and keep bookmarks lightweight. Need to remove a tag? git tag -d v1.1.0 deletes it locally — and if you deleted one by mistake, just re-tag the same commit (find it with git log --oneline, or fetch the tag back from the remote if you'd already pushed it).

Try It: Cut a Release