Dear Dyske,

first of all: *That's not a git problem ;)*
branches are the same (but a little bit better) than in SVN.
Forks are repo copies.

handling forks might be in some cases more tricky than a classic "branch" 
if you want to "backport" bugs / features to existing clones.

*I think you should start using git with a single private repo using 
branches as like before!*
If you are familiar with git in some future, you might find a way to 
replicate and manage forks for your business needs but there are no "tools" 
that will help you here. Just have a look at the "*git flow*" paradigm and 

Another suggestion, which is obvious but would not work, is to create a 
> branch for each website. This wouldn't work because the concept of "branch" 
> in Git is almost completely different from SVN.

that's wrong. the "concept" is likely the same. But yes, it's different how 
worse SVN allows bad users working with the SCM. git is much more cleaner 
and yes, in a single repository (clone) you just have a single "checkout" 
at a time. The really difference is for "you" how to manage them.
If you need different websites aside: just create a copy of your 
repository! You then have to update different repos if there are changes on 
the remote site.

so far, so good. But ... (if you intend not soly change your SCM but also 
your way how to work *using forks*)

I don't understand your gitHub "problem" while it is just a virtual problem:

   1. yes, gitHub (don't know since when) denies to fork on the same user 
   account via web-interface.
   2. you still might "fork" a repo manually but you'll loose the github 
   meta information that this is a fork. IE: you are not able to add push 
   requests to / between these repositories
      1. just clone your "basesite"
      2. create new repo called "forkedsite" via web but don't let gitHub 
      add files
      3. rename the remote "origin" (for basesite) to something like 
      "parent" and add the "forksite" remote as a new origin
      4. push your master to the new origin which now has the same tree-ish 
      as the parent
      5. (re)set uptracking branch if needed
      6. on updates on you parent repo: fetch --all && merge --no-ff 

Perhaps you might have a look at 

   - private repos are free unlimited up to 5 users
   - forking a repos of your own account is possible via web

As a git starter I don't know if *submodules *are very helpful yet for your 
Please regard: That you need a real "basic framework" or "components" that 
you might update independently.

As a webDeveloper you should have a look at composer<>
 or ( will help too that bundles bower).
So your dependency management might be more code-based instead of strict 
versioned submodules with all it's gaps and traps.

With kind regards,

Am Dienstag, 18. Juni 2013 23:42:06 UTC+2 schrieb Dyske Suematsu:
> Hi All,
> I spent a whole week researching this and found no answer. So, I'm hoping 
> that someone here could help me. Here's my situation which I don't think is 
> so unique or strange.
> I have a generic website that I always use as my starting point to build 
> websites for all of my clients. Since each client's needs are different, I 
> end up editing different parts of the original code. (In other words, I 
> cannot separate and isolate files that all sites share in common.) As you 
> could imagine, without some sort of version control, it would be very 
> difficult to manage all the websites. The same fix/change would have to be 
> applied to all the sites individually.
> Currently I manage them with SVN. The original, generic site is in the 
> "trunk" and for each new client, I create a branch. If I make a change to 
> the trunk that needs to be propagated to all the branches/sites, I just run 
> svn merge to merge trunk into branches. I've been doing this for some years 
> and it's been working fine.
> Now, I would like to switch to Git because it's more powerful overall, but 
> I cannot figure out how I can manage these sites with Git. I searched this 
> Google Group and found someone who asked a similar question. I also asked 
> some of my programmer friends who have been using Git for a long time. They 
> all suggested to create a fork for each website. I thought it would work, 
> so I started implementing this but hit a wall. The issue is that on Github, 
> each fork requires a unique user. Say, I create the "Official" repo under 
> my "Organization" account. The URL would be:
> I then create a fork of this, and I would end up with:
> Now, if I want to create another site, I would have to create a new user 
> because each fork is differentiated only by the user name. If I have to 
> create a new user for each website, eventually, I'll end up with a whole 
> bunch of user accounts to manage. And, since this must be a private repo, 
> each user would cost $7 a month and it can quickly amount to thousands of 
> dollars a year. So, this strategy hit a wall here.
> Another suggestion, which is obvious but would not work, is to create a 
> branch for each website. This wouldn't work because the concept of "branch" 
> in Git is almost completely different from SVN. Git does not create a 
> separate directory for each branch; it just switches the same directory. 
> So, if you have 20 websites, you would have to constantly switch between 
> different websites and you could never pull up two sites side-by-side on 
> your local machine. Furthermore, websites these days have files and folders 
> that the users upload (like photos). You wouldn't want to put them into the 
> repo but you do need them to switch when you change from one website to 
> next. Managing all this would be confusing and difficult under the same 
> working directory.
> Submodules and Subtree are two other suggestions but these would require 
> me to separate and isolate the files that are common to all sites. As I 
> said above, I cannot do this because each client has different needs.
> I don't think my situation is so uncommon. It's a situation where you 
> spin off a bunch of different versions from the same original codebase and 
> each is a legitimate product of its own (not a temporary state to be 
> discarded or merged at some point). Git is a powerful and flexible tool, 
> so I'm thinking that there HAS TO BE a solution for this. If anyone has any 
> idea, I would appreciate it very much (I would buy you lunch if you are in 
> New York).
> Thank you,
> Dyske

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to