Our revision control workflow uses some branching conventions combined with some access policies to ensure that work being done in parallel by a number of developers can proceed with a minimum of collision-caused trouble, and with maximum safety.

There are three tiers of repository:

• The off-site/archival “vault” repository
  This repo resides in codehub, and is only read-accessible. No direct changes will be made to this repository.
  
• The central development “shared” repository
  This repo resides on the development server, and is where all developers will push their changes to.
  
• Individual developer “clone” repositories
  Every developer will have one or more of these, which serve as the “working space” for code changes to be made and committed.
  

Only build/release admins will have write-access to the “vault” repository in codehub. The only route for changes into this repository is a push from the shared development repository. This will only be done per release, by a build/release admin, and can be deferred until all aspects of a release and the associated changes are fully vetted. This repository also serves as an off-site backup.

This is the repository that all developers will clone their individual working repositories from, which means it is also the repository that will receive the pushes of changes from developers. The only direct changes made in this repository will be official release merges to the master branch, performed only by a build/release admin, for the purpose of integrating changes for a release. When a release has been built, tested, and deployed successfully, it can then be pushed to the codehub repository.

These are cloned from the shared development repository, and serve as working space to make, and ultimately commit, changes. When ready, changes are pushed from these, by their respective owners, to the shared central repository.

These practices and policies are implied by the structure of the repositories.

The master branch of the central shared repository is locked, allowing no changes to be pushed to it from any clones. This protects the primary change history from accidental damage. It will only be manipulated via merge from the development branch, and only by a build/release admin, at build/release/patch time. This may, at some point, be automated