How to add a tag to a main branch of a code repository in GitHub?

Question

I'm fairly new to Git (and GitHub) and all my many years of version control come from using ClearCase, so I'm conscious of the fact that I might expect something of GitHub that does not exist.

I have a large python project which I want to bring under version control in terms of GitHub management and an internal version number of our own (held in a text file inside the project root).

After several branches have merged back to the main/master branch, I would like to add some kind of identifier (like a tag), which contains an incremented software version number as described above, to all files across the repository. I understand for files that don't change often tags will stack up.

I would like to use this tag (with the software version number) as a means of retrieving a specific version of the project files when legacy code needs to be retrieved for a rerun of the project. I understand that GitHubs has labels assigned to issues, but I am struggling to visualise how this would work (again, I'm stuck in a very old ClearCase way of thinking).

Answer 1

TL;DR

You don't need to do this file by file, just use git tags.

The longer story

I faced your issue when I migrated from CVS to Git. My source files used to include version numbers inside them, automatically updated by CVS during my commit process (if I recall correctly). This way, when I looked at a file, I knew which version I was looking at. I fought Git for a while, trying to keep this going, but what I have learned, and my advice to you: just stop keeping version info inside each source files. It's just not Git's model.

Take the time to get familiar with Git's each-commit-is-a-full-snapshot model, embrace it, and you will soon realize how much simpler what you want to do actually is with Git in the first place.

When you check out a particular commit with Git, via its sha-1 or using a tag, you get the state of every single file in the project as of that commit. You no longer need to track which version each file had at that time: that's exactly what a commit does.

I used to keep track of things like "release 1.0 needs file A 1.0 file B 2.4 file C 1.2". My release process had a step that created that list and embedded it in each release. With Git, that's "release 1.0 needs commit <sha1>", which becomes "release 1.0 needs tag v1.0" if you use tags. I no longer feel the need to embed this information is my release, since my tag's name is self explanatory.