We are using 3 remotes with Git on a team with 5 people. Here's how we do it:<p>* "dev" branch: This branch holds all development code and code being tested on our development site<p>* "master" branch: After code has been fully developed and tested, it's moved into the master branch. This code sits on our staging site.<p>* tags: We tag commits on the master branch, which represents a production release. We tag releases using the format YYYYMMDD.##, so if there was a release today, it'd be 20100929.01. If there was another, the ending number would increment.<p>All development is branched off of master to start in a feature branch. Once it's ready for testing, it's merged to dev. When it's considered ready for release, the topic branch is merged into master. After final testing, master is tagged and the feature is released into production. We use a shared central repository on the network, rather than trying to manage branches between one another.<p>One consideration you might want to think about is "dead" code in your development branch. We have had instances where, for whatever reason, code was developed in a topic branch, merged into "dev", then development stopped. It could have been changing priorities, changing requirements, "oh never mind, we don't want that", or whatever. To combat the issue of "dev" having a bunch of junk (which confounds testing), we "refresh" it monthly. An automated process on our continuous integration server simply deletes the "dev" branch and re-creates it off of "master". Then, an email is sent to developers telling them to do the same thing and to merge their topic branches back into "dev". Of course, this means that "master" and the topic branches must have all our code, no development must be done in "dev" directly.<p>To automate all this, our continuous integration system (Hudson) monitors the "dev" and "master" branches. If there is a change, it runs some basic checks (lint, unit testing, etc), then rsync's the code to the appropriate web server automatically. For production releases, it's (intentionally) a more manual process. Tagging must be done manually and a programmer must go into the CI server to kick off the production release by specifying the tag to release. If we need to roll back to the previous release, the process is the same.<p>I think having a central repository and a system automate deployment to the remotes is essential and probably more important than your particular git branching scheme. It's made our lives much easier and has caught countless problems (and spammed us via XMPP) that we might not have noticed if programmers were just "git push"ing to the web servers.