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?

  • 2
    What kinds of tags are being used? Are they useful once the PR is merged?
    – mmathis
    Nov 18, 2022 at 17:04
  • tags are usually related to the version, like "2.1". But, it can be misleading since version "2.1" on master two weeks from now might be different then the PR version of "2.1". Nov 18, 2022 at 17:13

1 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.