My team of developers are currently working at a client who has required us to move away from SVN and begin using their native workflow program. (Source tree by Atlassian). We are data warehouse developers and utilise primarily the Microsoft SQL stack for development.
The stack is commonly:

  • SQL Server Analysis Services (SSAS)
  • SQL Server Integration Services (SSIS)
  • SQL Server Management Studio (SSMS)

We also utilise a data-visualization tool named Tableau Server.

At the client these tools are used to develop simultaneously across four subject areas, for the purpose of this we will call them Subjects Areas; W, X, Y and Z.

Each subject area gets its own lot of solutions in all three SS programs as well as some files associated to tableau.

Since switching to sourcetree we have had a workflow of a master branch which reflects the work that will be migrated to the production environment. As well as a development branch which all developers commit to on a frequent basis.

After a large bug was detected in one of our subject areas we needed to revert back to the last good commit for the production environment. This was nearly impossible due to the large number of commits and merges and our disorganised gitflow.

This leads me to the question:
What is the ideal way to manage in effect the development of four subject areas across four programs simultaneously using github?
From my reading it would seem that 18 branches (4subject x 4 programs + Master + Dev) is a solution however this seems to be overkill.

Points to note:

  • All subject areas are developed simultaneously.
  • Programs (SSMS/SSIS) are developed by multiple developers simultaneously in different subject areas.
  • We have changed our master branch to be a sole reflection of our production environment with no extra commits already.
  • We only have access to a single repository.
  • Some work on some programs (SSIS for Subject X) are developed but never merged to production. This work needs to be maintained though.

As this is a subjective question, any opinions or further clarification is welcomed.

1 Answer 1


Summary: Vanilla Git Flow is pretty sane. For code that exist next to each other, use directories rather than branches. Feature branches should be short-lived, and don't introduce additional develop branches for each program and subject.

For projects of a certain size – and your project is well past that point –, the “Git Flow” describes best practices for Git branch management. The central branch is the develop branch, which is used for integration of features. If you do continuous integration testing, this is the branch you test. The master branch is always in a production-ready state and only lists previous releases.

As an aside: the master branch being production-ready does not imply that the contents of the master branch will literally be deployed in production. Although it's sometimes used as one, Git is not a deployment system. Instead, the master branch describes the states of the project that can be used to create the actual deliverable. This (hopefully automated) build process can then ignore subjects, programs, or really any files that are not needed for the that build.

There are now a couple of workflows that make up the Git Flow:

  • Releasing: When we want to release, we create a temporary branch from develop and perform release testing. Any work associated with releasing (such as minor fixes or bumping the version) can be committed on this branch. Once everything works out, this branch is merged into master and develop, and the merge commit on master is tagged with the version number. So master represents the current release, master^ the previous release, and so on.

  • Development: Development happens on relatively short-lived feature branches. These are forked of develop. Once they are complete, they get merged back into develop. If these branches are long-lived, it's a good idea to rebase the feature branch onto develop on a regular basis in order to prevent large merge conflicts. Also, keeping features small is a good strategy to make merging more pleasant.

  • Hotfixes: are not relevant here.

This is outside of the scope of Git Flow, but it can make sense to subdivide feature branches further, for large features that require the immediate collaboration of multiple people (this is not the default!). The sub-team working on this feature could treat the feature branch as if it were a local develop branch, and merge their own sub-features into this branch using the normal development workflow. Once the feature is ready, it would be merged into the main develop branch. However, this subdivision has certain dangers: The feature branch and the main develop are likely to drift apart over time. This can be counteracted by having a liaison developer regularly merge the main develop into the feature branch (which acts as the sub-teams develop branch). But when this mega-feature is merged into the main project, the impact for everyone else will be substantial and disrupt smooth development. Therefore, such over-complication should be only used as a last resort. It's preferable to have lots of small feature branches.

If we try to follow the Git Flow, having 4 subjects × 4 programs = 16 develop branches is not recommended. Quite likely all of that shouldn't be in the same repo, but if you have to, just use different directories inside the repo. You don't need a separate branch for each topic (i.e. subject, program). Git Flow uses branches to keep track of multiple threads of development (in the case of feature branches) or to signify the status of the code (in the case of develop and master).

As an analogy: I'm storing a blog about cats and dogs in a Git repo. I do not have two long-lived branches cat and dog where I write all posts about cats and dogs, respectively. Instead, I'd create a new feature branch for each post, but all cat-related posts are kept in the cat/ directory. Once the post is complete, it can be merged back into the main branch.

  • Thank you for that answer, you have cleared up a lot of questions I had about properly using git in our organisation. I will comment here what our workflow becomes after we have this discussion. Jan 18, 2015 at 20:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.