In a nutshell:

  1. All developers push to the remote master
  2. Acceptance testing is done against the master
  3. Once accepted, the release is tagged
  4. The release is exported to production
     with `git archive` or `git checkout-index -a`

For larger teams you might need fine-grained control, but it works great for our small team.

Thanks for the input. I've been noticing a pattern of "don't use version control in production" which makes complete sense with the export. Do you guys have any kind of staging environment where things get final approval from a third party? I'm in a situation where we have a client approval process which requires another intermediary to production. It basically sits on the same production box but is used for testing prior to going live.

If it helps with anybodies responses, my situation is particular to web development.

staging would fit well within the work flow outlined above: you just branch out a staging branch, and export that. If the client needs any fixes, you fix it on the stating branch, and merge it back to master.

That way, further development on master won't disturb staging.

Once the client is happy, tag staging and export it to production.

We use this:

http://nvie.com/posts/a-successful-git-branching-model/

How would one take this git flow model and add a third environment, staging, to sit between master and develop?

My initial thought would be to not change anything in the structure and to simply run a deployment script to export to the staging site using scp/ssh/rsync and ensure things are working properly before doing the same thing on production.

Just think of the release branches as staging branches--once something's ready to move from develop to staging, you make a new branch, so you can keep working on develop while you test staging.

Probably bears saying that you can install git-flow which takes care of a lot this for you. It's pretty neat. You might like it!

I've looked into and played around with git flow. I decided against it due to the abstraction. I'd much prefer if everybody on the team understands the underlying commands. I'll probably end up looking at the source to keep my bash-fu in check to see if there is anything the branching model article missed.

Same here. It's straightforward, just forward the link to everyone.

Concurrent development with maximum flexibility:

It might be a bit hard to follow, but this is the branching strategy we follow. http://tinypic.com/view.php?pic=15wi351&s=7

We use jira for managing our code changes and requests. Each ticket has its own branch. Everyday we merge the tickets we want to go out into a release branch, as you can see in the image. Release, then merge into master once we are satisfied with the release.

The benefits of this strategy is having maximum flexibility in releasing any code change. A request can be made, completed, and released in the same day, often in combination with changes that have been in progress for weeks.

The draw back is managing which branches are going out when, more so with teams greater than 20. It takes knowledgeable team leads and release managers.

We are using 3 remotes with Git on a team with 5 people. Here's how we do it:

* "dev" branch: This branch holds all development code and code being tested on our development site

* "master" branch: After code has been fully developed and tested, it's moved into the master branch. This code sits on our staging site.

* 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.

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.

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.

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.

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.

This isn't exactly what you are looking for. But this is what we use to handle our tagging and deployment to staging/production. http://github.com/apinstein/git-deployment. It's a capistrano multi environment recipe that automates a lot of the tasks.

I understand that git is the new hip version control, but if everyone uses it with a 'master' branch... why bother? Why not just use subversion? It defeats the whole purpose of using a distributed version control system.

Fair question. Two reasons (at least):

1. Git is much, much faster than Subversion. A real-life example: merging two branches with about 2,000 commits worth of changes (~250K lines added, changed or deleted) took over 6 hours with svn but <15 minutes with git. It's not just network overhead, our network is plenty fast.

2. Though you push to a remote master, that doesn't mean you can't branch locally. You can and you should; it makes it easy to work on multiple features simultaneously.

Then there are things like `git stash` and `git archive` that make life just that much better.

This is how we do it. http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-te...