VS Code / Git - is it possible to "drive a stake in the sand" at a given point in time and say "This all works"?

Another newbie question:

Given a project with a number of interrelated files that may, or may not, be working at a given point in time:

Assume that there is a point in the development of these files where I have reached a point where they all work, (at least to a certain extent), perhaps with things left to do.

The normal view of a Git repository, (GitHub), everything is a linear jumble differentiated by cryptic commit hashes with no sense of context.

What I want to do is to take the group of files that make up this project and - as a unified collection - say "This works at this point in time" - so that if something happens I have a known-working set of files to refer back to.

This would refer to specific versions of specific files as opposed to the entire linear commit history.

What I have researched:

1. Tags
   Tags appear to be a way of labeling individual files, not a collection of them as a unified whole.

2. Releases
   This sounds like what I want, but the idea of a "release" scares me because it implies that the project is, (at least semi) "ready for prime-time". Unless you happen to have a robot exactly like mine, with an operating system exactly like mine, configured exactly like mine, and a joystick that's exactly like mine, then this won't get you very far and I don't want a million issues raised because my code's a piece of GAGH!  (and it IS a piece of GAGH - this is a training exercise to help me learn things, not a project for public consumption.)

Ideas are welcome.

Solution 1:

What you want is a tag - when you add one you are marking that point in time across the entire repository with that tag - not the files as you state.

If I were to 'checkout' your repository at your tag. say the 1.0.0 tag, I would get ALL the files at that point in time.

Look into Semantic Versioning - X.Y.Z based versioning scheme.

Confusingly - differing VCS providers (GitLab, GitHub etc) use the term 'release' for differing things. GitHub will actually create a 'release' from a tag... so you end up with them in the releases list.

Also - look into 'branching'... This allows you to 'branch' off your known working version of the code with something new and awesome... that may or not work, or break things. If you get to a point where you think "Hrm, I need to do something on the known working version, but my current branch version is really broken" - you can checkout the old branch and go back to where you were, without loosing any work. (Providing obviously you have been committing your work).
This is a really simplistic use case for branches, but when you work with large teams they become invaluable.