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

  • Git - Create a new remote branch out of an old commit
  • Git: created new branch from a wrong branch
  • git checkout branch from outside
  • How do you handle the tension between refactoring and the need for merging?
  • git branch without history
  • What are the core concepts of git, github, fork & branch. How does git compare to SVN?
  • View a file in a different Git branch without changing branches
  • Rename branch on github website?
  • Paperclip files get deleted after each deploy
  • How to get started deploying PHP applications from a subversion repository?
  • What are branches in Git?
  • How to run git commands on remote without having local repo
  • 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.