tags vs branches in git
We have a large rails project that runs on a production and staging server. Is it a good idea to create tags everytime we deploy to staging or production (this would happen automatically with capistrano). Or is better to create branches named “devlopment” and “staging”, (master would contain the production status)?
- SVN tags: How not to update/checkout them?
- Tutorial on the life-cycle of a forked GIT repository while using remote tags
- Version numbering with SmartGit
- git show only tagger and date for tag
- How to install a tagged commit from a local Git repository using Composer?
- Git: How to create a tag that also include submodules?
3 Solutions collect form web for “tags vs branches in git”
You can use branches for development, staging and production and at the same time use tags to identify production versions. I like the way
git flow handles those branches and enables you to use more branches to develop new features. As a developer you would never have to commit code to the master branch, and merges into master are rare too.
Tags in git are pretty long-lived: they automatically propagate when you fetch from a remote repository, and if you want to clean them up you have to do so manually in every copy. Therefore, I’d rather use branches (and possibly their reflogs) for marking automatic deployment, because otherwise I’d probably be buried in lots of tags very soon.
We tag each of our deployements (automatically in our deployment scripts) for the purposes of quick recovery if needed, but they also come in handy as a deployment history. For example:
deployment_stag_20120804 deployment_stag_20120823 deployment_prod_20120715 deployment_prod_20120724
You can make your script keep tags for only the last N number of deployments if you want to avoid a huge amount of tags.
A branch makes more sense if your method of deploying is to merge, for example, into a production branch, upon which a git hook might trigger a pull on the prod server.