Git Tag Name Validator
Check a tag name against Git's ref-naming rules and see whether it is a sensible release tag.
What is Tag Validator?
A tag name validator. It applies the same rules as git check-ref-format, then adds the release-specific advice: release tooling and package managers expect strict semver, and a tag that sorts below the previous release causes no end of confusion.
How it works
The name is tested for the reserved characters and sequences git refuses, for path-segment rules, and for the reserved `HEAD` and `refs/` forms. Numeric names are checked against semver so `v1.4` is flagged as likely to break tag-parsing tooling, and comparing with the previous tag reports whether the new one actually moves forward. The commands to create, retag and push the tag are generated alongside the verdict.
- Paste or fill in the input. Drop in a commit message, a diff, a package.json, a path list or a set of options. The tool reads it locally — nothing is uploaded and no repository is contacted.
- Adjust the rules to match your project. Every linter here takes its convention from a setting you can change: allowed commit types, header length, target branch length, known branch names. Set them once to what your team actually uses.
- Copy the result. Generated files copy straight to the clipboard or download as a real file with the right name (.gitignore, CODEOWNERS, LICENSE, COMMIT_EDITMSG), and Reset returns every field to its default.
Examples
A commit message that fails CI
"Updated(auth): Fixed the expired-token redirect." is rejected by release automation and reported here with the exact reasons: unknown type, capitalised description, past tense and a trailing period.
A .gitignore that only half works
The Checker shows which rule decides a path — and why `!keep.txt` inside an ignored directory never fires, the mistake that sends people to Stack Overflow.
A dependency bump nobody reviewed
The package.json Diff separates added, removed and changed entries per section, so a caret bump of a runtime dependency does not hide inside a lockfile-sized pull request.
A diff pasted from a code review comment
The Diff Viewer understands several `diff --git` blocks, mode-only changes, renames and binary stubs, and calls out a pasted `--stat` summary instead of rendering an empty box.
Common mistakes
Committing a .gitignore without checking it
Rules look right and behave differently: a pattern containing a slash is anchored to the root, a trailing slash means directories only, and a file inside an ignored directory cannot be re-included. Check the paths that matter before you commit the file.
Rewriting published history
A clean commit history is worth having, but amend, rebase and filter-repo change commit hashes. Only rewrite commits that nobody has pulled; after a rewrite, push with --force-with-lease rather than --force.
Treating a generated file as if it were reviewed
These tools produce a starting point, not a decision. Check the licence text against the canonical source, read the security policy before publishing it, and make sure a CODEOWNERS team actually exists — GitHub silently ignores rules whose owner has no write access.
Putting slow checks in a pre-commit hook
A hook that takes 30 seconds gets bypassed with --no-verify within a week, and then it protects nothing. Keep pre-commit to formatting and linting, move type checks and tests to pre-push or CI.
Frequently asked questions
Should tags start with a v?
Both `v1.4.0` and `1.4.0` are widely used; the important thing is consistency, because automation strips or expects the prefix. npm and many CI templates strip a leading `v`, so pick one and stick to it.
Why is a tag and branch with the same name a problem?
They share one ref namespace, so `git checkout release` becomes ambiguous once both exist — git prints a warning and later commands may pick the wrong one. Release tooling that resolves `release` as a branch then breaks.
How do I move a tag I created by mistake?
Delete it locally and on the remote, then re-create it — `git tag -d v1.4.0`, `git push origin :refs/tags/v1.4.0`, then tag the right commit. Never move a tag people may already have fetched; cut a new patch release instead.