Tags and Cherry-Pick

Title

Tags and Cherry-Pick. Name a moment, copy a change.

This tutorial covers tags, which name important commits, and cherry-pick, which copies chosen commits to your branch.

Analogy: a name sticker that never moves

A tag is a fixed name on one commit, like v1.0. Unlike a branch, it stays put when you commit.

A tag permanently names one commit, so you can always find a release such as v1.0 later.

Create a lightweight tag

git tag v1.0 tags the commit you are on. Add a commit ID to tag an older commit.

git tag v1.0              # tags the current commit (HEAD)
git tag v0.9 4e5f6a7      # tags an older commit
git tag                   # lists all tags

Without extra options, git tag creates a lightweight tag, which is simply a name that points at a commit.

Annotated tags for releases

For releases, use an annotated tag. It stores the tagger, the date and a message.

git tag -a v1.1 -m "Release 1.1: dark mode"
git show v1.1

Annotated tags are full objects with their own author details and message, which is why Git recommends them for releases.

Tags do not travel by default

git push does not send tags. Push one tag by name, or all tags with --tags.

git push origin main       # commits only, no tags
git push origin v1.0       # one tag
git push origin --tags     # every tag

Tags stay on your laptop until you push them yourself, either one by name or all together.

Analogy: photocopying a recipe card

git cherry-pick copies the change from one commit and adds it as a new commit on your branch.

Cherry-pick applies the same change on your branch as a new commit, while the original stays on its own branch.

Pick one commit

Find the commit ID on the other branch, switch to your branch, then cherry-pick it.

git log --oneline source-branch
# 9d8e7f6 Add dark mode
# 8b7c6d5 Fix footer link
# 1a2b3c4 Add footer
git switch main
git cherry-pick 8b7c6d5

You name the commit to copy by its ID, and Git applies its change to the branch you are on.

Ranges: A..B leaves out A

A range A..B picks the commits after A, up to and including B. A itself is not copied.

git cherry-pick S1..S3

In the range A..B, Git copies what is reachable from B but not from A, so A is left out and the copies are applied oldest first.

Include A with A^..B

To include A, start from its parent: A^..B. Now A, B and everything between are copied.

git cherry-pick S1^..S3

The caret means "parent of", so starting the range at A's parent makes A part of the copy.

Conflicts and good habits

Cherry-pick a few specific fixes, not whole branches. On a conflict: fix, git add, then git cherry-pick --continue.

git cherry-pick --continue    # after fixing and git add
git cherry-pick --abort       # give up and go back
git cherry-pick -x 8b7c6d5    # note the source ID in the message

Cherry-pick is best for a small number of commits, and it stops for conflicts the same way a merge does.

Recap

Tags stay put. Annotated tags for releases. Push tags yourself. Cherry-picks are copies with new IDs. Use A^..B to include A.

{"commits": [{"id": "C1", "parents": []}, {"id": "C2", "parents": ["C1"]}, {"id": "C3", "parents": ["C2"]}, {"id": "C4", "parents": ["C3"]}, {"id": "C5", "parents": ["C4"]}], "refs": [{"name": "main", "target": "C5", "kind": "branch"}, {"name": "v1.0", "target": "C2", "kind": "tag"}], "head": {"ref": "main"}}

You can now name releases and copy chosen commits, and next you will learn to read and fix history.