Two Git repositories share common code

Question

So I have a project which has the client parts and the server parts. I would like the client and the server code to be in different Git repositories for clear separation of the code, however, they share some of the files and ideally, the shared files will always be identical in both client and server.

How should I go about this? Is it better to have the third repository for the common code?

Answer 1

I will not give advice on “How you should go about this”. But I'll explain how to accomplish integrating a third repository with common code into the other repositories: This is a job for git submodules. git submodules allow you to reference a snapshot of a git repository at a specified path:

git submodule add git://example.com/repository.git path 

Afterwards create a commit. Now a snapshot of the given repository is referenced at path.

Populating the submodule

1. Execute git submodule init
2. Execute git submodule update

Every configured submodule will be updated to match the state it is supposed to look like.

Updating a submodule to a later commit

1. Change into the directory of the submodule
2. Perform a git pull / git fetch + git checkout to update the submodule to the desired commit / tag
3. Create a new commit to update the commit in the .gitmodules file

Take a look at the official manual for further information on submodules.

Answer 2

If they share common code, I see two sensible options. Separate the common code into its own project, or merge the server and client repositories to make working on them together easier.

Whether separating the common code is worth the extra effort is up to you. Does the common code make sense on its own, or is is just a bunch of functions specific to this product? For example, if you had an SSL or date parsing code in common that would make a good spin off project. Or maybe you've written special code for config file parsing, that can be worked on stand-alone even if nobody but your project will use it. If you're spinning off common code just because the two projects share it, don't bother, it will have no direction of its own. Spinning it off will just be a barrier to development for both the server and client teams.

Whether you should merge the client and server is another consideration. It also comes down to whether it makes sense to consider them as separate products. Are they useful as separate products? Can different versions of the client and server work together, or must they be the same version? Do different people work on the client versus the server? The fact that you want to keep everything together in one super-repository says no.

If you do separate into multiple repositories (client, server, related projects) follow TimWolla's answer.

If you're not sure, merge them all into one repository with server/, client/ and common/ top level directories. If their concerns are entangled, put them together. This will also make it easier to spot and migrate duplicated code. You may work on disentangling them and creating concrete "common" projects, and at that time they should be spun off into their own repositories.