I am a bit new to git. I just moved over from SVN and I am trying to figure out some things.
I have a system with three types of contests (three different sets of functionality) and each of these would have contests off of them (so type 1 would have 3 contests and type 2 would have 2 and type 3 would have 4 for example) and the contests off the type are all based on that contests code base, just with different html/css. The contest system is MVC, so it is 1 controller, 1 model, and 3 views + assets (css/js/images).
I am trying to figure out how it is best to store these. In subversion I just made 15 billion branches, but now that I am moving I’d like to clean it up a bit.
Any suggestions?
Branching is actually significantly cheaper/cleaner/easier in Git, so there’s nothing stopping you from continuing to branch. 15 billion might be slightly excessive though.
You should simply be merging your three “types” of contest applications into one app that changes its behaviour based on a config file though. The kind of split functionality you’re talking about isn’t the problem that version control is meant to solve.
The “Git” way to proceed would be to clone that one application into a completely new app for a specific deploy and add the custom client-specific CSS/HTML to the new repository. Any changes to the underlying functionality would be done to the parent project and pulled into the forked projects.
You shouldn’t be making 200 divergent branches in the same repository for specific clients. There is no benefit, and one huge down-side: Every time you want to clone the repository for a specific client installation, you’re going to be dragging every single other client’s data (include the entire history of their assets) across the network. The overhead will be prohibitive.