Tags

• Tags is a static text pointer to specific commit
• Tags are used to add release versions to the project

CI/CD and Staging/production environments

• Software is developed according to CI/CD principles
• Continuous integration / Continuous delivery (or deployment)
• The division of staging and production environment are part of CI/CD approach

• Tests are set up for every merge

• Staging (release branch)

• Primary for testing

• Usually for internal use
• Merging is performed frequently
• Different feature branches are merged into release branch

• Multiple people may have merge rights

• Production (master branch)

• For stable production service

• For customers
• Merging happens each 2 weeks or 1 month
• Usually only release branch is merged into master branch. Exception is for a hotfix
• Only few people have merge rights

Semantic Versioning

• Common approach of numbering software versions.

• v5.1.3 -> Major: 5, Minor: 1, Patch: 3

• Major: New feature incompatible with previous versions

• Minor: Small feature that doesn't break anything in previous version

• Patch: Small bug fix

• Pre-release version

• v5.1.3-1.3: release version: 5.1.3, pre-release version: 1.3
• Release candidate (rc): It's a preview of the official version (which is launched afterwards). E.g. 2.0.0-rc.2
• Beta versions: beta feature

Annotated vs. Lightweight

• Lightweight
• It's stored at .git/refs/tags (simply a pointer to the commit)

git tag v1.0.0

• Annotated
• It's stored at .git/refs/tags
• It's also an object! It's stored at .git/objects. It has its own SHA1 hash
• Stores tag message, author & date
• It's recommended to create only annotated tags
• Tag names are unique

git tag -a v1.0.0 -m "New tag"

Draft new release

• Allows to create a new version from a specific commit in Github