Git branching scheme for ASP.NET MVC project with Areas

Question

1. Repository folder structure:

 - repository root
   -- ASP.NET MVC4 Project Folder    
      --- Views & Controllers
          ---- Index, Login, Dashboard, Common styles and scripts
      --- Areas
          ---- Area 1
          ---- Area 2

2. Conditions

• Given 3 projects (Dashboard, Area 1-2) are being developed almost independently as they are separate tools sharing same database and some of business logic.

• Areas share some of the styles, templates and scripts of the root project

• Release dates of projects are different, every project should be able to be deployed separately keeping others untouched.

3. Problem

How to organise git branches scheme to satisfy the conditions

Necessity of Area usage (instead of separate asp.net mvc projects or simple subfolders in one project) is not a question, we do need it to be this way.

---

My best idea so far was to have branches organised like this:

 - Release    //currently released branch, hotfixes go here
 - Master     //next release candidate
 - Dev        //current aggregated development version
 -- Dashboard  //work on the root project goes here
 -- Area 1     //work on Area 1 goes here
 -- Area 2     //work on Area 2 goes here

• Dashboard and areas pull updates from Master only.
• Dashboard and areas push updates to Dev to test integrated solution.
• Dashboard and areas push updates to Master whenever they are proven to be ready for next release.

But there is something incomplete and suspiciously smelling about this solution.

Answer 1

Ended up doing it like this:

With git's ability to pull/push to/from different remote branches we can keep our current permanent feature branch checked out and sync with remote DEV branch easily.

Works perfectly.

Answer 2

• Given 3 projects (Dashboard, Area 1-2) are being developed almost independently as they are separate tools sharing same database and some of business logic.

• Release dates of projects are different, every project should be able to be deployed separately keeping others untouched.

You've got the answer in your question: those are three different projects. Each project should have its own repository. Branching is not meant for this kind of workflow and I'm afraid, using them to manage separate projects in one repo will be a pain.

Create a repo for each of those projects and a fourth repo for your whole application. Add those three projects as submodules. This way you'll be able to manage the subprojects separately and also freeze combinations of their states as releases of your larger project.