Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Two Git repositories share common code

Tags:

git

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?

like image 412
Alex Napitupulu Avatar asked Feb 06 '15 01:02

Alex Napitupulu


People also ask

How do I share code between git repositories?

By using git submodules , you can have an independent repository inside a parent repository. So you have your web and mobile repository and then inside it, in a folder, the shared code repository. If you cd into the shared code folder, you can pull, commit, make branches and push back to the shared code.


2 Answers

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.

like image 75
TimWolla Avatar answered Oct 07 '22 00:10

TimWolla


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.

like image 42
Schwern Avatar answered Oct 06 '22 23:10

Schwern