Using Git Branches to deal with the multi-config variations of TeamMentor

Here is an interesting problem that afects TeamMentor (TM)  and just about every other app:

"How to deal with the specialised versions of an application that are created via Config changes"

Keeping this simple, and only dealing with the config changes that can be made by modifying the TmConfig.config file, TM already (today) has the following scenarios to support:

• Default install (with default settings)
• Anonymous users cannot see the content (with a variation where anonymous users cannot see the Library View (not done via config change))
• Redirect all Http traffic to Https (i.e. SSL Redirect)
• Windows Authentication enabled/disabled
• SSO enabled/disabled
• Change location of TM Libraries
• Enforce HTML Sanitisation on Article content
• Change default admin pwd

There are also other scenarios that I'm sure TM will need to support very soon:

• Read-only version of TM
• 'Secure / lock-down' version(s) of TM
• OAuth integration
• Support for 3rd party data sources (like the PoC done where wikipedia, msdn and owasp content is consumed by TM natively)

I was thinking about the ways to solve this, and here are a couple options:

1. Rely on user documentation and pass the responsibility to 'apply the changes correctly' to the customers/users (I don't like this solution, although is what most vendors do (including SI))
2. Create forks that apply the required changes only to those repositories (this is what we currently do in the forks we maintain)
3. Make changes on specialised Git Branches, and use Git Checkout to enabled them (hum.....)

As you can see by my comments:

• I really don't like option #1, 
• option #2 is what we currently do on some cases (and does have the side effect of fork-explosion), and 
• option #3 is an idea I have been thinking for a while, and the more I think about it, the more I like it.

Basically the idea would be to use Git Branches to track/apply those config changes.

Currently we use Git Branches to hold references to past TM versions (like we do at the moment in the 'master TM repositories'). Note that the Git Branches used for special dev tests on Dev forks would not be affected by this.

What I really like about this idea is:

• it would put the responsibility to create those 'variations' in the most capable hands (i.e. the ones who know the code best) 
• it would allow for a strong QA cycles and for much better support for those scenarios
• it would make life easier for customers/users
• it would provide a scalable way to support complex configuration changes (i.e. scenarios that require more than a couple 'settings-changes')

What do you think?

Any other ideas on how to deal with this issue?