Git Submodule or fork

I have a private repo in github that is the complete source code to my cms. Now I have a few local customers that I want to use the same code base on but with different themes. Is it better to fork the original project out into a repo for each one. Or use a submodule and create a new repo for each customer?

After each site is complete I would imagine the theme files wouldn’t change much but would need to pull in changes from the main repo when bugs are discovered.

  • Forking a fork of my repo in GitHub
  • Set up more than one 'automatic' remote when cloning git repo
  • Git: forks with specific folder's content remaining different in each repo (not considered in merges)
  • github fork fetch all the changes from the original repo
  • How do I get back to my earlier commits after fixing a forgotten fork?
  • Tutorial on the life-cycle of a forked GIT repository while using remote tags
  • Git pull upstream branch not working
  • How to deal with merge/pull in git
  • Merge branches without uncommited changes
  • In Git, how can I reorder (changes from) pushed commits?
  • Can I only squash 2 commits at a time?
  • How to add the cvs head of a project as dependency?
  • One Solution collect form web for “Git Submodule or fork”

    Since there is two set of files involved (the common based, and the theme files), then submodules are appropriate.

    Each client would have:

    • a main git repo project
      • one submodule cloning the common code base
      • one submodule with specific files for its theme.

    Forking is more a cloning technique able to isolate one version of a repo from its copy.
    GitHub implements it with a fork queue to facilite cherry-picking back some changes made in forked Git repo.
    But the key thing here is: it concerns the all repository, not just one part.
    If several parts are involved, submodules are the right answer.

    Git Baby is a git and github fan, let's start git clone.