0

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?

Improve this question
1
  • lol it's a bit of an exaggeration but I had at least 200 for last year. Commented Feb 27, 2012 at 15:14

2 Answers 2

Reset to default
3

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

1

I've had previous experience like this one. I had two versions of the same product, both with minor modifications. Although the codebase was larger, I used the following way and, to say, it did a good job for me.

  1. Create the vanilla branch with the common code all the products should have.
  2. Create the product branches with the code, that is specific for each of the product.
  3. Continue development of common functionality in vanilla branch and merge that code into the product branches.

Hope it helps.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.