No Login Data Private Local Save

Git Semver Tag Generator - Online Create Release Tags

7
0
0
0
Version Editor
Paste any semver tag to auto-fill all fields
breaking changes
new features
bug fixes
Pre-release tag: none
Build metadata is ignored when comparing versions.
Full Tag Preview
1.0.0
v1.0.0
Git Commands
$ git tag -a v1.0.0 -m "Release version 1.0.0"
$ git push origin v1.0.0
$ git push --tags (push all tags)
Recent Tags

No tags generated yet. Start by configuring your version above!

Frequently Asked Questions
Semantic Versioning (SemVer) is a versioning scheme that uses a three-part number format: MAJOR.MINOR.PATCH.
  • MAJOR – Incremented for incompatible API changes (breaking changes).
  • MINOR – Incremented for new backward-compatible functionality.
  • PATCH – Incremented for backward-compatible bug fixes.
Optional pre-release labels (like -alpha.1) and build metadata (like +build.123) can be appended.
A Git tag marks a specific commit as important, typically used to mark release points (e.g., v1.0.0). Tags help you and your team quickly reference specific versions, roll back to stable states, and track the project's release history. They are essential for CI/CD pipelines, changelog generation, and package managers.
Annotated tags (git tag -a) store extra metadata: tagger name, email, date, and a message. They are checksummed and are the recommended choice for releases. Lightweight tags (git tag without -a) are just pointers to commits with no extra data. Use them for temporary or personal references. For public releases, always prefer annotated tags.
By default, git push does not push tags. Use:
  • git push origin <tagname> – Push a single tag.
  • git push --tags – Push all local tags to the remote.
  • git push --follow-tags – Push only annotated tags that are reachable from pushed commits.
Pre-release versions indicate that a release is not yet stable. Common patterns include:
  • Alpha (1.0.0-alpha.1) – Early testing, may be unstable.
  • Beta (1.0.0-beta.1) – Feature-complete but still under testing.
  • Release Candidate (1.0.0-rc.1) – Potentially final, last round of testing.
Pre-release versions have lower precedence than the normal version: 1.0.0-alpha < 1.0.0.
The v prefix (e.g., v1.0.0) is a widely adopted convention, especially in the Git and open-source community. It helps distinguish version tags from other tags. Many tools (GitHub Releases, npm, Go modules) recognize both formats. Consistency is key – pick one convention and stick with it across your project.
  • Delete locally: git tag -d <tagname>
  • Delete from remote: git push --delete origin <tagname>

Be cautious when deleting tags from shared repositories – this can cause confusion for other contributors.

Build metadata is appended with a + sign (e.g., 1.0.0+build.20240101). It is ignored when determining version precedence. Use it to embed CI build numbers, commit SHAs, or timestamps without affecting version comparison. Example: 1.2.3+sha.abc1234.
  • Always use annotated tags for public releases.
  • Follow Semantic Versioning strictly.
  • Keep a CHANGELOG.md documenting each version's changes.
  • Tag from the main/master branch after all tests pass.
  • Sign your tags with GPG for added security: git tag -s v1.0.0.
  • Use CI/CD to automate tag creation on merge to main.
A Git tag is a native Git feature that marks a specific commit. A GitHub Release is built on top of a Git tag and adds a rich UI with release notes, binary attachments (assets), and a dedicated page. GitHub Releases are great for distributing compiled binaries and communicating changes to users. Every GitHub Release requires an underlying Git tag.
🔧 Related Tools