Does Git, SVN, etc do this type of "branching & merging" or something like this?

Client has different versions of the same code based, basically they copy a template code base, then edit the copy, and then use that copy in production as an instance of the code. Meaning there's 20 versions of the code base running, but 80% of the code is the same. Without changing their workflow is there a way to merge the source code and then do builds of the code if the code changes in the VCS for each of the builds/branches. Code is in Perl if that matters.

If so, what is this called, and does the VCS manage the "builds" (it's Perl, really just versions of the code).

Visual: A,B,C custom code branches; X is shared code

   |
   |
   X
   开发者_开发技巧|
  /|\
 / | \
A  B  C
 \ | /
  \|/
   |
   |
   X
   |
   |
   |\
   | \
 A,B  C
   | /
   |/
   |
   |
   X
   |
   |      
  /|
 / |
A  B,C
 \ |
  \|
   |
   |
  Etc... Where X = 80% of the code.
   |
   |      

Yes you can, but before I explain it, I have to strongly recommend that you not do this. It is much better to separate the variable stuff from the shared stuff, and turn the shared stuff into some kind of framework, which could be as simple as moving the variable stuff into a "sites" directory (I'm guessing you are building canned web sites) with 20 subdirectories that the framework chooses from (adds to the module path) at runtime (use lib "sites/$site"; might do the trick, but don't quote me on that).

If you really, really have to manage this via version control, you can simply create a branch for each site, maintain the core code base on master, and regularly merge from master to each site in order to propagate updates. If the variable and shared code are cleanly separated, this will rarely require human intervention.

I suppose this could be done with branches, but I think it'd be more ideal to just have a smarter templating system that knew how to load the correct version of the template. If you insist on using branches, you could do it by having a master branch (in Git parlance) that has all the common code, and a branch for each variation. Changes to a specific version could be done on the relevant branch, while changes that should effect everything could be done on the master branch. You'd have to merge the latest master changes into each branch individually, however, unless you wrote some sort of automation for it. Again, I don't think using branches for something like this is the best idea, but you might be able to make it work.

In Git, you can have multiple complete clones of a Git repository, where each one is its own full repo.

• Make a new branch called client/custom
• Make client changes and commit them to client/custom
• Make the changes in the "origin" repo.
• Commit the changes in the origin repo.
• Pull the changes from origin/master into client/master
• Rebase client/custom to the latest client/master OR merge the latest changes from client/master into client/custom.

This may not be the quickest way to do it in Git, but it can work (assuming you manually resolve any wonky merges, of course.)

See http://git-scm.com/docs/git-rebase