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)?

  • “TAG - diff” in gitweb - is it possible?
  • Tag multiple branches in git?
  • Git tags referring to different refs on local and remote
  • Will Git Force push overwrite/delete tags
  • How to list all tags pointing to a specific commit in git
  • Change root of a branch in git
  • GitPython tags sorted
  • Git clone through http:// does not clone all tags
  • 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:


    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.

    Git Baby is a git and github fan, let's start git clone.