This project is read-only.
How we do branching

Our organization established policy to create a branch for each iteration as it is moved from the development environment, moved to a staging environment and then another branch as software is deployed to the production environment. The BranchPolicy enforces this policy programmatically by allowing for 3 different areas for branches Development, Staging, and Production and then also designates the Integration Branch that functions as the main branch or trunk.

Here is how a typical branch relationship diagram might look for a that has been deployed to production and has another branch in development:

|- $/MyPrettyProject/Development/Release 1.0
|- $/MyPrettyProject/Integration
|- $/MyPrettyProject/Development/Release 1.1
|- $/MyPrettyProject/Staging/Release 1.1
|- $/MyPrettyProject/Production/Release 1.1
|- $/MyPrettyProject/Development/Release 1.2

So the rules are simple, when creating a branch;
  1. if the target path is for development, then the source path must be the Integration branch.
  2. if the target path is the Integration branch, then the source path must be from development
  3. if the target path is for staging, then the source path must be from development
  4. if the target path is for production, then the source path must be from staging
  5. finally if the target path is not anything from above,

Last edited Jul 11, 2012 at 4:33 PM by thisisntjared, version 2

Comments

No comments yet.