Multiple Similar Sites with GIT? Or some other version control?

324 Views Asked by At

I just took over a web development position for a company that manages a lot of different sites. There are a couple different site "designs" and for each design, there's a couple cookie-cutter type versions of the same thing. They're different sites, but the framework is so close to the same, that since only the content and some styling changes, the previous guy had just been copy-pasting these to the specific hosts.

So my question is whether or not Git is the right thing for this? I've used git a little bit on my own side-projects, but we're talking hundreds of sites (about 10 per design) for this job. Would a bunch of branches be a good way to go? Mainly, what I want to be able to do is quickly and easily update the common files. The previous guy was just using a perl script to transfer things over to "update" the sites when we made a global change. Seems like it would be much more fool-proof and controlled (version controlled) with git.

Subversion was another thought of mine, but I don't have the access to install that on all the servers. Most files are transferred via ftp, but with some finagling, I could probably get some ssh (I'd probably set it up with fuse for sshfs) going as well.

Any thoughts? Or, if I'm going about this completely wrong, let me know, also. I've never dealt with anything this size (i.e. lots of sites) before, and it just seems really messy. I know there's a better way to do it!

Thanks!

2

There are 2 best solutions below

0
On
  1. Separate development and deploy into different tasks (no need to have a repository /or just WC/ on every production)
  2. Any SCM with good branching-merging will work
  3. Common part of all sites (framework) can be separated (or at least you can try to do it) into one entity, linked to final products (using SCM-specific methods - submodules, externals)
0
On

git submodules remain a good way to keep track of other repos, including:

  • one for common file
  • one for specific file.

That means that each of your website is a "parent" repo which includes the two submodules mentioned above.

The trick is, especially for the submodule representing common file, is to declare it in a website as "following the latest commits of a branch".

git submodule add -b master common url/to/common/files/repo

That way, each time you have to work on one of those website repo, all you need to do first is a:

git submodule update --remote

And you are sure to work with the latest up-to-date common files.