Introduction

A GitHub release does not point directly to an arbitrary commit. It points to a Git tag, and the tag points to a commit. So if you want to change the commit "connected" to a release, what you are really doing is changing which commit the release tag refers to.

That distinction matters because the safe workflow depends on whether the tag already exists, whether the release is published, and whether other users may already depend on that tag. Moving a public tag is possible, but it should be treated as a potentially disruptive operation.

How Releases, Tags, and Commits Relate

In GitHub:

• a release is metadata and release notes
• a tag is the Git reference name such as v1.2.0
• the tag resolves to a commit

If the release is attached to tag v1.2.0, then changing the release commit means moving v1.2.0 or replacing it with a new tag.

You can inspect the current tag target locally:

git fetch --tags
git rev-list -n 1 v1.2.0
git show --no-patch --oneline v1.2.0

That shows which commit the release currently represents.

Best Option: Create a New Tag

If the release is already public and other people may have fetched the old tag, the safest fix is usually to publish a new version tag instead of rewriting the old one.

For example:

1git checkout main
2git pull origin main
3git tag -a v1.2.1 abc1234 -m "Release v1.2.1"
4git push origin v1.2.1

Then create a new GitHub release for v1.2.1. This avoids surprising anyone who already downloaded artifacts or pinned the old tag in automation.

Moving an Existing Release Tag

If you intentionally need the existing release name to point somewhere else, you can move the tag locally and force-push the tag update.

First delete the old local tag:

git tag -d v1.2.0

Then recreate it at the correct commit:

git tag -a v1.2.0 def5678 -m "Retag v1.2.0 to the correct commit"

Push the updated tag to GitHub:

git push origin :refs/tags/v1.2.0
git push origin v1.2.0

The release attached to v1.2.0 will then refer to the new commit, because the tag now resolves differently.

If your team prefers a single command, some Git servers support force-updating the tag directly:

git push --force origin v1.2.0

Even when that works, the delete-then-push version is easier to reason about because it makes the replacement explicit.

Draft Release vs Published Release

If the release is still a draft and the tag has not been finalized, the easiest route is often to edit the draft in GitHub and choose the correct target before publishing. That avoids rewriting a public tag.

Once the tag is published and consumers have seen it, the tradeoff changes:

• moving the tag preserves the same version name
• creating a new tag preserves history and avoids confusion

In most release processes, the second option is better.

Verifying the Result

After pushing the updated tag, verify both Git and GitHub:

git ls-remote --tags origin | grep v1.2.0
git show --no-patch --oneline v1.2.0

Then refresh the release page in GitHub and confirm the tag now resolves to the intended commit.

If CI, deployment jobs, or package publishing steps read release tags, check those too. A moved tag can trigger unexpected behavior if downstream systems cached the old tag object.

When Not to Move a Tag

Avoid moving an existing release tag when:

• the release has already been widely consumed
• package managers or deployment tools rely on immutable version tags
• your team uses signed release tags and audit trails
• you can ship a corrective patch version instead

Retagging is technically simple, but operationally it can be messy. Anyone who already fetched the original tag may need to delete and refetch it before their local repository matches the remote again.

Common Pitfalls

The biggest mistake is editing the release notes in GitHub and assuming that changes the underlying commit. It does not. The tag is the real link between the release and the code.

Another common mistake is moving a public tag without warning the team. Other developers may have the old tag locally, and automated systems may already have built artifacts from it.

Developers also forget that annotated tags are separate Git objects. If you recreate the tag locally but never push the replacement tag to the remote, GitHub will keep showing the old commit.

Finally, do not rewrite a tag casually when a new version number would communicate the correction more clearly. New tags are usually safer than mutated old tags.

Summary

• A GitHub release is attached to a tag, and the tag points to a commit.
• To change the release commit, you must move or replace the tag.
• The safest public fix is usually to create a new tag such as v1.2.1.
• If you must reuse the same tag, delete and recreate it at the correct commit, then push the update.
• Always verify the new tag target locally and on GitHub after the change.
• Treat moved public tags as a coordination problem, not just a Git command problem.