Tags & Releases
You shipped app.py at the commit everyone now runs, then kept committing on top. Weeks later you need that exact snapshot back, and one small file, written once and never rewritten, still points straight at it.
- ▸Tag
v1.0, make a hundred more commits, and.git/refs/tags/v1.0still holds the first hash. It never follows you. - ▸The same commit, tagged two ways, is reached by two shapes: one hop, or a detour through a small object.
- ▸
1.4.7plus one backward-compatible feature is1.5.0, not1.5.7: a bump zeroes every field to its right.
You cut release v1.0: the project is at commit 04b74b1, and you want a name that always means *this exact snapshot*. So you place a tag called v1.0 on it. Then work continues, e626e62, then f1b91f2, two more commits land on main.
Look at two files. .git/refs/heads/main now holds f1b91f2, the newest commit: the branch followed you forward. .git/refs/tags/v1.0 still holds 04b74b1, the commit you started from. Committing advanced one file and left the other untouched.
That is the whole behavior of a tag: a name pinned to one commit that later commits never drag along. A branch is a label that moves; a tag is a label that stays.