This project has moved and is read-only. For the latest updates, please go here.

Is it OK to just have a Main & Release(s) branches with no Dev Branch?

Jul 12, 2012 at 12:01 AM

Is it OK to just have a Main & Release(s) branches with no Dev?
A co-worker is recommending this approach. Is this a common branching scenario?
What are the pros & cons of not having a separate Dev Branches?
Your feedback on the following would be appreciated. 

BRANCHING SCENARIO (Without using Dev Branch)

  1. The Release 1 branch is created from Main for working on your next release.
  2. (Optional) Periodic merges into Main ensure bug fixes from the release are moved into the main integration branch.
  3. The release build is labeled in the RTM (Release to Manufacturer) branch and merged back into Main.
  4. A service pack, SP1 (or hotfix), is released. The build is labeled and changes are merged into Main.
  5. The Release 1 branch lives on in support of SP1 and to enable future service packs.
  6. These process then repeat for all future releases (release 2, 3, and on…)

Once deploy to PROD and merge back in to the Main App tree, we must label the build (version 1.1.0, or 1.1.1, etc.) so we have the checkpoint to branch from it if we need to. I recommend to only keeping the previous release branch active while we’re working on the next. All releases before that can safely be deleted off Release Folder to avoid cluster and save space in your TFS. We can always branch an old version using Label so there’s no point of keeping multiple releases active beside the current and the previous released branches.

Jul 12, 2012 at 2:48 PM

Yes this approach is fine.  There is no magic to always having a dev branch, you are in a basic 2 branching model here, and if that is the isolation you need then that will work well.  Keep in mind that your plan to only keep the previous release active (not deleted) I assume is due to the fact that you are only supporting the 1 release at a time in prod?  For example, I would keep as many release branches active as I had out in production somewhere.

Jul 12, 2012 at 8:15 PM

I have a different perspective. The Main branch should be kept as stable as possible, throughout its lifetime. This allows it to be deployed at any time to a testing environment (QA, UAT, Staging, etc). For this reason, all development should be isolated into one or more development branches (children of main), Development, should be fairly stable before being merged (RI) with Main. Further stabilization can take place in Main, while development continues in a Dev branch. Branching for Release is much preferred over using labels. Release branches can be locked down (made read-only). The contents of a label are NOT immutable. Many organizations require the auditability provided by branches that cannot be provided by labels. Ongoing development should not be taking place in a release branch. Code, once stabilized for release, should be branched for release from Main. TFS is very efficient at saving "diff" files and compressing large files. If the same version of a file exists in two separate, related branches, only one version of the content is stored in TFS. Having separate Release branches for each active release version in production (or deployed to customers), may be a minimum audit requirement in most organizations.

I believe the Ranger Branching Guide makes a strong case for this approach.

Bill Heys, VS ALM Ranger

Jul 13, 2012 at 1:14 AM

mlhoop & wheys - Thank you both for the advice. 

wheys (Bill Heys)- thank you for the detailed info on why it isn't a good idea to do branching without a dev branch and for explaining TFS space saving techniques it uses and about labeling.  I will share this my organization.