How to structure git repositories for project?

Question

I'm working on a content synchronisation module for Drupal. There is a server module, which sits on ona website and exposes content via a web service. There is a also a client module, which sits on a different site and fetches and imports the content at regular intervals.

The server is created on Drupal 6. The client is created on Drupal 7. There is going to be a need for a Druapl 7 version of the server. And then there will be a need for a Drupal 8 version of both the client and the server once it is released next year.

I'm fairly new to git and source control, so I was wondering what is the best way to setup the git repositories? Would it be a case of having a separate repository for each instance, i.e:

Drupal 6 server = 1 repository
Drupal 6 client = 1 repository
Drupal 7 server = 1 repository
Drupal 7 client = 1 repository
etc 

Or would it make more sense to have one repository for the server and another for the client then create branches for each Drupal version?

Currently I have 2 repositories - one for the client and another for the server.

Answer 1

Unless the project is really huge, I'd go for single repository with subdirectories for server and client and create a branch for each version. You can still have multiple copies of the repository in case you want access multiple versions at the same time.

By maintaining multiple repositories, you'd make transferring changes harder than necessary (rebase is easier than applying patches). In the (improbable) case there'll no changes to be applied to multiple versions, you still lose nothing...

Moreover, you can always switch to multiple repositories: Just clone the repo and remove the branches you don't want. Going the other way round is harder.

I'd go for multiple repos only if the server and client share nothing or if the code is really huge.

Answer 2

I have seen and worked with such variations. Everything in one folder with subfolders for server and client or one repo each. I prefer the single repo for every main part of the project.

In case of big version changes I would simply create new repos too. Definitely not have different branches for them. While branches are powerful for implementation of new functionality and maybe one permanent deployment branch, I always avoid having too many of them run parallel for a long time. You will always have to maintain them (do rebases when the master branch changed etc), so keep the basic structuring as simple as possible. Having an extra repo is (in my humble opinion) less painful than juggling branches in different states. Especially if client and server don't share much code.

I don't know much about Drupal and how strong the differences between versions are. So my point to prefer different repos is based more on my experience with Rails. Between versions there are sometimes big differences in things like how files are named or the folder structure (eg asset pipeline) which makes it more comfortable to create a new repo. Drupal (or any other framework) may have less differences, then it would be ok to just go on within the existing repo.