# Versioning

Another aspect of Coding is Versioning.
I bet you have some folder on your Computer at home or at work.
Where there are at least two files that have names like:

  • Presentation2019_final.pptx
  • Presentation2019_final_2020.pptx
  • Presentation2019_final_v2.pptx

This is probably the attempt to version your files.
But it kind of sucks, right?

# Version Control

Version control is the process of capturing who did what at which time to the code.
Each Version needs a unique identity.
In the case of git***, it is an SHA 1 Hash value.
This allowed us to track changes back, and revert to them if needed.
Git however is NOT a Backup.
Code Hosting Services like GitLab, GitHub, Bitbucket or Azure DevOps can be, but you still have to have a Backup strategy.

# Git

Git essentially is a giant graph of differential changes called commit, a directed acyclic graph - DAG to be specific.

Each commit is a reference to its parent.
Branches are just named pointers to specific commits.
These commits are stored in an append-only database.
Gitlab Video to git

# Refs

A ref is an indirect way of referring to a commit.
You can think of it as a user-friendly alias for a commit hash.
This is Git’s internal mechanism of representing branches and tags.

HEAD is a pointer to the latest commit.

Just another alias.

"But what the hack is a commit?"
And how does Git know when to save changes…

# Workflow

Git workingtree
Git workingtree

Source
Your Project is in your Local Repo if you open a file, git makes a shadow copy of your file and put it in the working Directory or Working Tree.

Now you finished your work and add your work to the staging area.
This is the last chance to check your work.

With a commit you will now once and for all publish these changes to the append-only** database.****

Similar to Bitcoin or some other Blockchain, everybody can see your changes.

The last step could be to push your changes to a Remote Repository.
This is optional if you work alone, but mandatory if you work in a Team.

# Backup

The Remote Repo can serve as part of a Backup.
But it is only one part of it.

I will make a post about that in the future but follow the 3.2.1.1.0 Backup Rule.

3 - Maintain at least 3 Copys of your Data.
2 - Store on two separate media types.
1 - At least one of the Copy must be offsite.
1 - One Copy must be Offline.
0 - Be sure to have verified backups without errors.

# .git Folder

Each Repository has a .git folder in the root directory.
This Folder contains all the info.

  • Hooks – Folder: Extend git with user functionality
  • index – Binary File: Staging area where git add and git rm apply.
    • Use the git ls-files --stage command to see all staged files.
  • HEAD – Tracks what's currently checked out, gets updated by the git checkout command.
  • Refs – Folder: Can be Heads (Branches) or Remotes or Tags, which are a way for semantic versioning.
    • All refs contain an object ID.
    • cat refs/heads/main Will return the Object ID.
  • Objects – There are 4 types of Objects
    • Tree – Dir Tree
    • Commit – Snapshot of changes
    • Blob - File contents
    • Tag – Named ref
  • config
  • Logs

# SemVer

Semantic version numbers are more suited for Release versioning.
If you publish an API for example, over time you will do some breaking changes to it, so you version it and can refer to it by the version number.

Major.Minor.Fix-pre-release+Build
Major (Breaking functionality to older versions)
Minor (Added Features and improvements)
FIX (Bug fixes and small changes like typos)
Every Version before 1.0.0 is recognized as unstable.**

# Conclusion

So now that we have everything as code and we version it automatically
what should we use it for?

There is a lot of content out there about writing apps.

So let's look into Automation.