0

I have a website that I've tracked in git since I started working on it. Now I want to build a second website using similar code. My first thought was, "Ok, I'll just clone ClientA's repository, rename the clone to ClientB and start from there." But that doesn't seem to me like the ideal way to organize this. Ultimately, I think I'd like to have a repo called something like WebsiteBoilerplate with several branches for each client.. or should I create separate repos for each client? Are there best practices for this sort of thing? or should I just do it however I feel? Once, I've determined where I need to go, I need some help getting from here to there as far as which commands I need to run.

Jo Sprague
  • 16,523
  • 10
  • 42
  • 62
  • http://stackoverflow.com/questions/6286571/git-fork-is-git-clone can be of help! – Ozair Kafray Oct 12 '12 at 19:16
  • One possible solution is common bits in it's own repository and each project in it's own repository. The common bits is just a submodule in the projects. Any way you can support both websites with one code base? like multi-tenancy, css files differ etc. – Luke Hutton Oct 12 '12 at 19:20
  • Thanks @LukeHutton That's one idea I had. I am actually using submodules in ClientA's repo. The thing is, it takes a little bit of work to rebuild a second repo using almost the exact same 6-10 submodules. That's why I had thoughts to copy the new repo from the existing one. – Jo Sprague Oct 12 '12 at 21:25

1 Answers1

1

Like everything it depends, but having a master branch where you develop the common code sounds like a reasonable approach. Then you can have different branches for each site, and keep the site-specific branches synchronized with the common master.

Creating a site specific branch is easy:

git checkout -b siteName

Keep in synch with master by merging or rebasing changes from master

git merge master

or

git rebase -i master

If you feel like having separate repositories after a while, you can do that as well. Just fork the main repo, and you can still keep in synch by pulling down changes from the "upstream" repository.

To fork in git (not the same as fork on github) I usually clone, rename origin to upstream and push to my new origin. I also set my local to track the new origin.

Assuming you already have a remote named origin, you want to rename it to upstream and setup tracking on the new origin.

git remote rename origin upstream
git remote add origin https://origin.git
git branch --set-upstream master origin/master
git push origin master

Now that you have common code in upstream and site specific in origin, you can track changes in upstream by:

git fetch upstream master #checks if there are changes
git merge upstream/master #merges master with the changes in upstream

You can combine the two commands above with git pull upstream master

ebaxt
  • 8,287
  • 1
  • 34
  • 36