Tags, Releases and Cherry-pick

• A tag is a fixed, human-readable name for one commit
• A branch moves as you commit; a tag never moves
• Typical use: label a release, like v1.0

• Lightweight: git tag v1.0 is a ref straight at a commit, no metadata
• Annotated: git tag -a v1.0 -m "Release 1.0" creates a tag object
• The object stores tagger, date, message and an optional GPG signature

• git push does not send tags
• One tag: git push origin v1.0
• All tags: git push origin --tags
• Safer: git push --follow-tags sends only annotated tags reachable from pushed commits

git tag -a v0.9 <sha> -m "msg"
git tag -l 'v1.*'
git show v1.0

tag an older commit by giving its sha; -l takes a glob pattern

• A bump resets lower numbers to 0
• Pre-release 1.0.0-rc.1 sorts before 1.0.0

• git cherry-pick <sha> copies one commit onto the current branch
• The result is a new commit with a new hash
• -n applies the changes but does not commit

• Replays the commit's diff as a three-way merge
• Conflicts when the target changed the same lines
• --abort abandons the pick; --skip drops one commit

• Backport = apply a fix from main to a maintained release branch
• -x appends (cherry picked from commit <sha>) to the new message
• It records the origin, so the pick is easy to trace and audit
• Not added by default; use it only for picks between public branches

git switch release-1.2
git cherry-pick -x 3f9a1c2
git log -1 --format=%B

the new commit gets a new hash

• git describe --tags --always --dirty
• Output tag-N-gHASH: N commits after the tag, e.g. v1.2.0-5-g3f9a1c2