At Real Travel we practice SCRUM) which allows us to release a new code base to the live server roughly every two weeks. Since moving to Git we now are able to track our releases in a more methodical manner using the git tag command.
The idea behind tagging
Take this scenario: your development team has just released to the live server what they thought was a bug free code base, but your QA team raises a red flag on a bug they just found. After they had released, the development team jumped onto the next project, building on top of the current code. Luckily, the development team tagged the release and are able to “go back in time” and find that bug without affecting their current work.
Tagging is like a sticky note in a text book that you can easily turn to for future reference. Whether it is to fix a bug or maybe even branch off a known stable release, it’s like the DeLorean for git.
The tagging solution
The following is an example how the development team above was able to fix their bug and release it with out any problems. Please note: the following code is examples on how to tag your local branches. Tagging directly on a remote branch is covered later below.
After the team released, they tagged the master branch:
1 | $ > git tag release_3 master |
Note: a tag name cannot contain spaces, ~ ^ : ? * [ ] or ASCII
Doing a git tag command without any parameters will list out all the current tags found:
1 | $ > git tag |
2 | $ > release_1 |
3 | release_2 |
4 | release_3 |
5 | ... |
The team now wants to make a separate branch of the tagged code so that they can fix the bug. Naming conventions is totally up to your team, but the more descriptive on what is going on the better.
1 | $ > git checkout -b from-release_3 release_3 |
What this does is creates a new branch ( -b ) from the tagged branch ( release_3 ) and renames the branch ( from-release_3 ) and checks it out. The team would then proceed like normal doing their typical workflow of development, adding, commit, etc.
Once they are certain the bug is fixed, they then merge the branch back into the current master, push to the remote and tag the new release:
1 | $ > git tag release_3.1 master |
2 | $ > git branch -D from-release_3 |
The second option is to delete the bug branch as it typically is not needed. You can also delete the first tag, but I recommend to keep it around until you know for certain your code works properly.
Remote tagging
As mentioned above, this strategy dealt around tagging local branches. In order for your entire team to have access to the tag, the tag must reside also on the remote. To make sure your local tag goes to the remote, you need to push its reference:
1 | $ > git push origin :tag_name |
2 | $ > git push origin --tags # only use this if you want all local tags on the remote |
Deleting a remote tag is simple too; just delete the tag from your local repository:
1 | $ > git tag -d tag_name |
2 | $ > git push origin :refs/tags/tag_name # --tags will not delete tags on the remote |
Keep your code (and team) sane
I know when emergency code fixes happen, things get pretty hectic. Luckily with the right tools in Git, hopefully they will become less. I am sure there are other strategies when it comes to releasing code, but this method is very straight forward and has helped out the Real Travel team a few times.