Should tags be introduced on commits still in Pull Request branches outside of main/master branch?

Question

Context: I am working on a project in which people use tags on commits yet in branches waiting on the Pull Requests queue of GitHub. This means they are non-merged to the main branch yet.

The problem from my standpoint of view is that Pull Requests are unstable.

Still as a PR, after some changes, interactive rebase, and force-pushes, a tag can be associated with the "wrong commit". This gets messy after the PR is merged on the main/master branch.

Hence, my suggestion for the team would be to wait for tags to be associated with "stable" code, on the main or master branch.

Is there any technical reason or advantage to allow tags on commits yet on Pull Requests review?

Am I missing something with my suggestion?

Answer 1

Tags are used to identify specific commits on long-lived branches for specific reasons. This is so you can quickly check out the codebase at that specific commit. As in your case, tagging with a version number is a typical use case for these - but it is the main branch that is tagged, not feature branches (e.g., see the gitflow workflow as detailed by Atlassian). In the gitflow example, you need to check out the tagged version of the main branch in order to implement a hotfix - not using tags makes that difficult, though not impossible.

There are a few problems with tagging a feature branch (some of which you've identified), especially when a PR is open for that branch:

• The branch is not long-lived. Once the PR is merged, the feature branch is typically deleted.
• The branch may be modified based on the review being done, meaning the tag could become out of date. The tag can be moved, of course, but easy to forget to do that.
• Perhaps most importantly, there is usually no reason to need to check out that specific commit, meaning the tag is pointless. When we tag the codebase with 2.1 for instance, we are saying that everything in the codebase at that point is contained in version 2.1, and everything that's been released in version 2.1 is in the codebase at that point. If you tag a feature branch with 2.1, neither of those are necessarily true.