0

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.

Jim JR Harris
  • 413
  • 1
  • 6
  • 15

1 Answers1

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.

Dan Streeter
  • 2,259
  • 2
  • 16
  • 16
  • Can I add a comment to the tagged group as a whole to provide context? Ahh, that creates a "release" anyway, so "release notes" should be available. – Jim JR Harris Jan 09 '22 at 20:10
  • For context within releases/tags/versions - check out Keep A Changelog (https://keepachangelog.com/en/1.0.0/) - a real nice format to keep a file with your repo to track your changes for human consumption. Some people automate creation of this, but I believe it should be for human consumption so written and easy to read. – Dan Streeter Jan 09 '22 at 20:15
  • I found this that talks about the differences between releases and tags - though there seems to be some convergence there. https://stackoverflow.com/a/18512221/7886968 – Jim JR Harris Jan 09 '22 at 20:17
  • Yes, as that post states, 'Releases' are a GitHub concept... GitHub is just a UI, or a service over the underlying technology 'git' (https://git-scm.com/). That post is talking how to get things via the GitHub API - something which isnt a thing in just 'git'... its a command line tool for version control and has no actual concept of 'releases'. – Dan Streeter Jan 09 '22 at 20:19
  • "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." Thanks for the tip! I did just that with a brilliant idea I had that turned out to be less-than-brilliant because it was not possible! (shrug). The result was that I was able to go back to the main branch and not have mangled code - a great feature! – Jim JR Harris Jan 19 '22 at 14:03