Tags

###When to tag? Every time you push to production (except you have a continuously delivering environment where each push is automatically delivered into production). Tags are needed to keep track of production releases.

###Usage There are three different types of tags: lightweight, signed and annotated. In most occasions we will use annotated.

git tag -a v1.2.0 -m 'Awesome tag message'

While pushing tags will not be automatically pushed. Use git push --tags

###Format of tags Consider v1.2.3. The tag name may be split as 'major.minor.patch'.

• major is used for substantial changes to an application (that are often break the compatibility);
• minor is used to capture new user value functionality;
• patch is used for bug fixes.

###Deleting git tag -d <tag>

git push origin :refs/tags/<tag>

More info

###Release branches When you want to release to production, but do not want to affect master branch you should use release branches instead of tags. Since tags point to one commit it is more convenient to use release branches while making hot fixes. Therefore, the format of branch names will contain only major and minor parts (e. g. rb1.3).

###Reasons to create release branches

• Manual QA
• Long running releases
• On demand hot fixes

###The process of bug fixing for production releases Let you have v1.0.0 and v1.1.0. Suppose you have found a bug in v1.0.0. The best practice will be to check out this commit, create a release branch from this commit and work on the bug fixing.