Boris Masis

Git pulls are a fairly easy way to deploy your code, and we’re doing just that at my new event promotion startup. We wanted to take our release process just one small step further by tagging our releases so that we know exactly what is running in production and when it got there. Instead of using formal release numbers we decided to just use a simple date system: YY.MM.DD.HH.mm (using leading 0s and the 24 hour clock). For example if I were to do a release right now I would tag it 11.02.04.17.44

If you are developing on windows, the following .bat file will take care of creating such a tag for you and pushing it to your remote repository (i.e. Github):

call git tag %date:~12,2%.%date:~4,2%.%date:~7,2%.%time:~0,2%.%time:~3,2%
call git push --tags
cmd

The next step in the deployment is to pull down the tag in QA:

git fetch
git checkout YY.MM.DD.HH.mm (referring to your previously named tag)

This process can be repeated in production, but if it fails QA testing we delete the tag with the following commands and start over.

git tag -d YY.MM.DD.HH.mm (to delete your local tag)
git push origin :YY.MM.DD.HH.mm (to delete the remote tag)
on QA: git tag -d YY.MM.DD.HH.mm (to delete the QA local tag)

If you’re not immediately creating a fixed release, update QA to the prior tag using

git checkout YY.MM.DD.HH.mm

As an alternative workflow, you could create your tags in QA after QA testing has passed, in which case you could create this bash file

tag=`date +"%y.%m.%d.%H.%M"`
git tag $tag
git checkout $tag
git push --tags