Tag without release

For our projects, we are using tags which seem to create releases associated with every tag. Is there a way to stop creation of releases with each tag?

I understand releases at the core are based on tags.

Related discussion: https://stackoverflow.com/questions/28496319/github-a-tag-but-not-a-release

> As of 2017-05-31, Github support has stated it’s “not currently possible as all tags will appear in [the release] list” - they said they’d pass it along as a feature request, though.


Seconded.  In our community a “Release” is a very specific thing and having tab called “Releases” with a bunch of tar files for every tag is confusing.


Hi @sarats and @rljacob,

Thanks for this feedback! We’re always working to improve GitHub and the GitHub Community Forum, and we consider every suggestion we receive.

As that StackOverflow answer relates, each tag creates a release point but does not actually create a release. Releases themselves are created when you add release notes to a tag. However, as you noted, tags that don’t have a release associated with them do still show up on the releases tab, albeit in a very different style. I can see how this could be confusing.

I’ve logged your feature request in our internal feature request list. Though I can’t guarantee anything or share a timeline for this, I can tell you that it’s been shared with the appropriate teams for consideration.

Please let me know if you have any other questions.




If you haven’t made a release yet, but have made tags, the release tab will be nothing but “release points” which all have the same look.  This is also confusing.


There are already 2 UI tabs: “Releases” and “Tags” 

However they both show the same content: All Tags (plus some releases information)

It would be interesting to have in the “Releases” tab only the actual releases, that contains other binaries or notes.


Hi @racer1988,

We appreciate the feedback. I’ll pass it along to the appropriate teams!



WHy can we even add tags without release or branches? When i add a tag using sourcetree the tag shows in the branch menu, yet i get a 404 when clicking one

Hi @schroef,

Is the repository that you’re having problems with a public one? You should still be able to view a tagged commit unless that commit is no longer reachable in the history and has since been purged.


I do see the tags, im using “keep a change log” method for easy workflow. In their example, each update start with a version, which is same as the tag… When you check this link, you see that the release version link to there comparison page automatically.

My guess this only works if you’re using branches and do pulls per released tag. I dont do that and simply work on one main branch.

WHy can we even add tags without release or branches? When i add a tag using sourcetree the tag shows in the branch menu, yet i get a 404 when clicking one

Because tags are different from branches, despite how Sourcetree displays them. A branch is a name for some unit of work that can grow and change over time, with commits added, subtracted, or changed. A tag is a name for a specific commit, a specific point in the repository’s history. While you can delete and recreate a tag, it is not typically done. A tag is intended to be fixed.

The “keep a change log” method doesn’t require any particular branching or tag structure. You could just point directly to commits using their SHA if you wanted and the change log format described at https://keepachangelog.com/ would still work. It is easier to use tags though because v1.0.0 is generally easier to type and remember than d20c188ff2c6353de3d8682ca94100d452c65479, even though they will both take you to the same point in history in the keepachangelog project because they are two different names for the same commit. And even if you do decide to use tags, you still don’t have to use branches or pull requests if you don’t want to. These are all optional features that are designed to make specific development or source control activities easier or more accessible.

If you want to understand more about how Git works and how commits, branches, and tags all work and interrelate, I strongly recommend reading Git from the Bottom Up by jwiegley.

I hope that helps!


People are always complaining “Why do I need to install autoconf to build the latest release?? Where’s the ./configure script??”

They are incorrectly trying to build directly from source code, because they clicked on this “Release” link that Github created without my authorization, when they should instead be building from the actual release distribution (created via “make dist”) that I’ve carefully prepared and uploaded for them.

Please stop this automatic creation of “releases” without asking, just because I’ve stuck a tag on something. Or, at least give me a button to turn it off.

Creating a tag and creating a downloadable release package are two completely different actions. Stop conflating them.


Another me-too!

My “real” release has just slipped onto page two of the releases list because of several recent tagged builds that are not releases. My users can’t find the production release any more causing confusion and a higher than desired support load.

I’d be very greatful if a GitHub business manager can increase the priority of this request and report on when it will be addressed.

Many thanks, Peter


I have the same problem and would also like to see tags not appear on the Releases tab.


Yet another “me too”.

This is about to become a bit of a pain when I start tagging (but not releasing) my code based on CI rebuilds when there are no source changes (at least in that repository).


Same here. Having a tag automatically makes no semantic and functional sense that would apply to everyone. Can someone from Github please look into this quickly? It has been a problem for a long time. 


Any chance to prioritize this?

I do not even see a point in this “automatic” releasing as the default automated release does not have any additional info compared to the original tag from which it was created. Anyone who would want that “release” can simply check it out.

The major problem however, as already stated in this thread, is that the repo snapshot is not automatically “build ready” as GitHub thinks, but people usually need to create specific source dist package which builds, because the repo snapshot builds just with the repo only.

Everything else about the Releases is perfectly fine, just let the people choose which tags they want to convert to releases and what actually should be part of those releases. Make any other automation (e.g. the automatic source snapshot generation) optional, because, it just brings confusion and frustration without any additional benefit.


For me, it sounds like a bug that it shows GitHub internal “release points” in Releases tab where user doesn’t expect it to be shown. It’s GitHub implementation detail and corresponds to tags one-by-one, so it doesn’t make sense to appear in Releases tab by default from user POV.

I also thought GitHub creates a release automatically when it’s tagged and looked for how to stop it… very confusing.


We’re also now getting complaints on making releases difficult to find because we tag things for our CI system https://github.com/Esri/lerc/issues/100.

1 Like

I’m sorry, but I have add yet another “me too”, hoping it will increase the probability for a fix :slight_smile:

I need to use tags in order to just save some “relatively stable commits”, which are far away from being a “release”.
I just would like my tags to not appear automatically under “Releases”, misleading many users that my tag “stable-N” is actually a release.

Vladislav Valtchev


We have the same problem -  please prioritize this!