Recall from lesson 5-2 the two options Git offered when it refused the switch: commit your changes, or stash them.
The exact wording was "Please commit your changes or stash them before you switch branches", which is Git naming both escape routes in the error itself.
Commit has been familiar since unit 2. This lesson collects the promised second option.
git stash: the drawer for half-done work
You are mid-experiment, files torn apart, nothing commit-worthy, and an urgent bug needs you on another branch immediately.
git stash takes every uncommitted change, both working directory edits and staged ones, saves them on a stack inside .git, and resets your files to match the last commit. The working directory comes out clean, which makes it in effect a drawer for half-done work.
$ git stash Saved working directory and index state WIP on new-sauce: c7d8e9f Add photo $ git status nothing to commit, working tree clean
Now you are free to switch, fix, commit, and push the urgent thing. Back on your branch, reopen the drawer.
$ git stash pop
Your half-done edits return exactly as they were, and pop removes that entry from the stack. git stash list shows everything currently stashed, since stashes accumulate if you use the command repeatedly.
One warning from experience. The drawer is easy to forget, and a stash has no name, no branch, and no message worth reading, so a stash from three weeks ago is a mystery. Stashes are for hours, not weeks. If the work matters, promote it to a real commit on a branch where log and the reflog can protect it.
A recorded session
This session walks the emergency swerve. Messy uncommitted changes sit on new-sauce, and main needs attention immediately.
Each step below shows the command and the output it printed.
Step 1. Sweep your uncommitted changes into the stash.
~/recipe-book $ git stash Saved working directory and index state WIP on new-sauce: c7d8e9f Add photo of finished pancakes
The message records which branch and commit you stashed from, which is the only context a stash carries.
Step 2. Confirm the working tree is clean.
~/recipe-book $ git status On branch new-sauce nothing to commit, working tree clean
Clean is the point. From here any switch Git previously refused now goes through.
Step 3. Emergency handled elsewhere, you are back. Restore your work from the stash.
~/recipe-book $ git stash pop On branch new-sauce Changes not staged for commit: modified: sauce.txt Dropped refs/stash@{0}
The Dropped line confirms the stash entry was removed after being applied, so the drawer is empty again and there is no stale copy to confuse you later.
Tags: naming the moments that matter
Branch labels move with every commit. A tag is the opposite, a permanent label on one commit, used to mark releases.
$ git tag -a v1.0.0 -m "First public release" $ git tag v1.0.0
The -a makes an annotated tag, which stores its own message, author, and date. That is the kind teams use for releases, since a release deserves a record of who cut it and why.
The name follows semantic versioning, written as major.minor.patch, so v2.4.1 means major version 2, the 4th batch of features within it, and the 1st round of bug fixes after that. Bumping the major number signals a change that can break existing users, which is the convention's real purpose.
Tags do not travel with a normal push, which surprises people the first time. Send them explicitly with git push --tags.
From then on anyone can run git switch --detach v1.0.0, the detached HEAD from lesson 9-3, and inspect exactly what shipped, indefinitely.
The key difference is movement: a branch label moves forward as you commit, while a tag stays permanently on one commit.
Both are pointers to commits, which is lesson 5-1's big idea applied twice. The mechanism is the same, and only the behavior differs.
A branch follows the work, which is what you want while developing. A tag is frozen where you put it, which is what you want for marking a release, since v1.0.0 has to keep meaning the exact code that shipped even after a year of further commits.
The command is git stash.
It stores all uncommitted changes on a stack inside .git and cleans the working tree, so a switch that Git would otherwise refuse becomes possible.
Two companions complete the set. git stash pop restores the most recent stash and removes it from the stack, and git stash list shows what is currently in the drawer, which is worth checking occasionally since forgotten stashes are the usual way this feature goes wrong.