stash and tags

git stash: the drawer for half-done work

You're mid-experiment, files torn apart, nothing commit-worthy, and an urgent bug needs you on another branch now. git stash takes every uncommitted change — working directory edits and staged ones — saves them on a stack inside .git, and resets your files to match the last commit, leaving the working directory clean. 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're 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. git stash list shows everything currently stashed, stashes stack up if you use it repeatedly.

One warning from experience: the drawer is easy to forget. Stashes are for hours, not weeks. If work matters, promote it to a real commit on a branch, where log and reflog can protect it.

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

-a makes an annotated tag, which stores its own message, author, and date, the kind teams use for releases. The name follows semantic versioning: major.minor.patch, so v2.4.1 means major version 2, 4th feature batch, 1st bug-fix round.

Tags don't travel with a normal push, send them explicitly with git push --tags. From then on, anyone can git switch --detach v1.0.0 (detached HEAD, lesson 9-3) to inspect exactly what shipped, forever.