How to organize various parts of a project in a git repository?

Question

In one project I need to organize several parts of the project. Web application written on php server, api written in nodejs and android and ios applications. Would it be nice to split them into multiple repositories? Or separate folders in one git repository

Answer 1

If you plan to reuse these separate “projects”, you should use the git submodule. However, if you do not, I would just separate them in different folders under one unique git.

Submodules

git is great for projects that can be "cloned" and updated in any other (large) projects.

Keep in mind that it adds some layer of complexity when working with submodules.

Answer 2

If the individual modules are sufficiently independent, you can use the git submodule to combine the two approaches. You will have one folder / repo in which you have a folder for each subproject. Each subproject is a separate repository and can be used as such, but you will be able to track the version of each project from the root repository, as well as issue “cooperative” commands to submodules, as in

git submodule update 

or "recursive" commands, as in

 git submodule foreach make 

You will find documentation and a kind of tutorial on the Internet.

Here is an example of setting up a repository containing several submodules (ncs, ..., test_network)

 git init git submodule add ssh://.../ncs ... git submodule add ssh://.../test_network vim Makefile #write the Makefile for the whole project git add Makefile git commit -i -m "Makefile added" git submodule foreach autoreconf -i git submodule foreach ./configure make test 

Answer 3

I would save them as separate projects. If you need to merge git repositories, you can always use git submodules .

Answer 4

I tried the “one repo per piece” approach for a project, which consisted of an external web application, an internal one, a Chrome extension, a website, and several shared libraries. This was primarily due to the fact that the libraries are open on GitHub and the rest of the code is proprietary.

Although this obviously worked fine for open source libraries, it turned out that there were several problems for private repositories:

• The update was slower. WebStorm (and possibly other IDEs) had to check this many additional repositories (about 10 repositories took about 30 seconds to check the synchronization of VCS and no updates). I ended up creating shell scripts that git pull in each directory were dependent on the current project (frontend / backend / etc.)
• Returning to a given command for parts of the project that depend on each other (for example, before changing the API) is not so simple - you need to check different commits in different repositories or use tags all the time. The easiest way was to see the commit timestamps.

The only good use cases I found for this template are:

• Repositions that need different permissions, for example. The open source component and native repo should obviously be separate. However, one private repo can contain several parts of the project that are private (for example, the interface and backend can be directories in the same repo).
• With separate issue trackers on GitHub, you don’t need to start each issue with “Q ... this is happening.”