Confusion about Git tags, merge requests branches and references

Question

Some context: I have a monorepo with a release process where we create a branch, generate a release commit inside the branch, create the according tags and then that release branch gets merged to our target protected branch (main).

My question is: If I create a tag in that release branch, and that branch is merged and then deleted, is my tag gonna loose the reference? Or is that reference from the branch the new HEAD in the target branch (main) and the tag will still be able to be referenced?

Inside Gitlab it all seems to work and keep references, but I'm trying understand a little bit better how this works.

Thanks!

Answer 1

Let's go over some very basic facts about Git.

The first thing to understand is that a "branch" is merely a name for one commit. Deleting the branch does not delete anything else. In particular it doesn't delete any commits! And it doesn't delete any other names that may be attached to a commit. And a tag is also merely a name for one commit.

Thus, as long as your merge is a true merge (with a merge commit that has two parents), no commits will be lost and no tags marking any of those commits will be lost.

Moreover, both a branch and a tag have an incredibly important magical property: they keep the commit that they point to alive! Therefore, even if you delete the "branch" (which, remember, is only a name), this will have no effect on the commit that has the tag: that commit cannot ever die no matter what, as long as that tag lives on.

Finally, it's good to know this: a commit cannot die as long as it is the parent of a commit that is alive. Thus, after the merge, the merge commit has two parents and it keeps both of them alive. The commit pointed to by the merged branch is one of those parents. Thus, the whole chain of commits from there on back is kept alive. So there's another reason to believe that everything will be okay.