Tags decide which commit a release points to, so a moved or deleted tag can change what users install. A GitHub ruleset that targets your release tag pattern can limit who may create, move or delete those tags and block force pushes. Set it up before your next release, not after a scare.
Why tags need their own rules
Most maintainers lock down the main branch and forget tags. Yet many installers, build scripts and CI actions resolve a version through its tag. If an attacker with push access can move v2.4.0 to a different commit, everyone who trusts that tag runs the new code. The change is easy to miss, because the tag name looks the same.
What a ruleset can do
GitHub describes rulesets as a way to control how people interact with branches and tags, selected by name pattern. Per the docs, a ruleset can control who can push, delete or rename a tag and can block force pushes. You can also let chosen roles, teams or GitHub Apps bypass the ruleset.
Two properties make rulesets handy for a small project:
- Several rulesets can apply to the same target at once, and where they conflict, the most restrictive version of a rule applies.
- You can change a ruleset's enforcement status without deleting it, between Active and Disabled.
Check the plan note: GitHub says rulesets are available on GitHub Team and Enterprise plans, and its page does not state how they apply to public repositories. Confirm in your own settings page what your account offers. If rulesets are not available to you, check what tag protection options your plan does include.
A sensible setup
- Target tags matching your release pattern, for example
v*. - Restrict deletion and block force pushes for everyone.
- Restrict who can create matching tags, so only your release process or a named maintainer can.
- Keep the bypass list short. A small named group is better than a broad role.
Then run your release as usual and confirm a test tag from another account is refused.
Combine with the other controls
A tag rule is one layer:
- Immutable releases lock the tag and assets after you publish. See what they lock and what they do not.
- A required-reviewer environment gates the publish job. See environments and required reviewers.
- Two-factor authentication on every account that can push.
None of these replaces the others. Each answers a different failure.
Document it
Add a line to your contributing or release docs saying who can create release tags and how. Reporters and downstream users sometimes ask, and the answer shows you have thought about it.
Quick check
Can a ruleset stop a tag from being deleted?
Per GitHub's documentation, rulesets can control who can delete or rename a tag and can block force pushes.
What if two rulesets disagree?
The most restrictive version of the rule applies.
Sources
Last reviewed: 19 October 2026.
