In Git, why don't tags travel with a normal git push, and what does --follow-tags do?

## Why tags are not implied Every push is a set of ref updates derived from refspecs. `git push origin main` expands to something like `refs/heads/main:refs/heads/main` — one ref. The commit objects a tag points at may well be transferred as part of that branch's history, but the *tag ref* is a separate entry in `refs/tags/` and nothing in the branch refspec mentions it. That is why the objects arrive and the tag does not: the remote has the commit, but no name pointing at it. This is deliberate. Tags are a global, largely immutable namespace shared by everyone who clones. Publishing them by accident, or moving one that others already fetched, causes far more trouble than a stray branch, so Git makes tag publication explicit. ## Three ways to publish - **One tag by name:** `git push origin v1.0`. Git resolves the short name; `git push origin refs/tags/v1.0:refs/tags/v1.0` is the unambiguous long form and is worth using when a branch of the same name could exist. - **All tags:** `git push --tags` sends every ref under `refs/tags/`, in addition to any refspecs given on the command line. Blunt but occasionally what you want on a fresh remote. On a long-lived repository it can publish years of local experiment tags. - **Reachable annotated tags:** `git push --follow-tags` sends annotated tags that are (a) reachable from the commits being pushed and (b) not already present on the remote, alongside the branch update. This is the surgical option: pushing `main` also publishes the release tags that belong to the history you just published, and nothing else. ## Annotated versus lightweight matters here An annotated tag is a real tag object carrying a tagger, a date, a message, and optionally a signature; a lightweight tag is just a ref pointing straight at a commit. `--follow-tags` deliberately considers only annotated tags, on the reasoning that lightweight tags are private bookmarks while annotated ones are published markers. The practical consequence bites people: create a release tag with plain `git tag v1.0`, push with `--follow-tags`, and the tag does not appear on the remote at all, with no error. Creating release tags with `git tag -a` (or `-s` for a signed one) avoids this entirely. ## Making it the default `push.followTags = true` applies `--follow-tags` to every push. This is a common team setting: release tags reach the remote with the commits they describe, without anyone remembering a flag, and without the shotgun effect of `--tags`. ## Updating and deleting tags on the remote Moving a published tag is hostile: clones that already fetched it do not silently adopt a new value, so different people end up with different meanings for the same name. The receiving side reflects this by refusing to update an existing tag ref unless the update is forced. Creating a *new* tag name is an ordinary update and needs no force. Deleting a remote tag uses the same forms as a branch: `git push origin --delete v1.0` or the refspec `git push origin :refs/tags/v1.0`. Deleting the remote copy does not remove anyone's local copy. ## Diagnosing "the tag isn't there" The checklist is short. Is the tag annotated (`git cat-file -t v1.0` prints `tag` for annotated, `commit` for lightweight)? Is it reachable from the branch you pushed? Did the push actually include it (`git push --dry-run --follow-tags origin main` lists the refs that would move)? And does the remote already have a *different* tag of that name, in which case the update is refused rather than silently skipped? ## The interview point The question tests whether you think of push as "upload my repository" or as "update these named refs". The strong answer names the refspec reason, distinguishes `--tags` from `--follow-tags`, volunteers the annotated-only restriction as the practical gotcha, and mentions `push.followTags` as the way to stop relying on memory.