CODEWITHSUNDEEP
git
Yalamber
Yalamber

Reputation: 7580

How to organize different parts of project in git repo?

In a single project I have to organize multiple parts of the project. A web app written in php, api server written in nodejs and android and ios apps. Would it be good idea to separate these in to multiple repos? Or separate folders in a single git repo?

Upvotes: 4

Views: 3552

Answers (4)

Dan Dascalescu
Dan Dascalescu

Reputation: 152027

I've tried the "one repo per part" approach for a project that consisted of a frontend web app, a backend one, a Chrome extension, a website, and a few shared libraries. This was dictated primarily by the fact that the libraries are open sourced on GitHub, while the rest of the code is proprietary.

While this obviously worked great for the open sourced libraries, it turned out to create several problems for the private repos:

  1. Updating was slower. WebStorm (and probably other IDEs) had to check this many extra repos (for about 10 repos it took about 30 seconds to check when synchronizing the VCS, and there were no updates). I ended up creating shell scripts that did git pull in each directory that was a dependence of the current project (frontend/backend/etc.)
  2. Reverting to a given commit across parts of the project that are dependent on each other (e.g. before an API change) isn't as easy - you need to check out different commits in different repos, or use tags all the time. It was easiest to look at the commit timestamps.

The only good use cases I've found for this pattern:

  • Repos that needed different permissions, e.g. an open-source component vs. a proprietary repo, should obviously be separate. However, one private repo can hold multiple parts of the project that are private (e.g. the frontend and the backend can be directories in the same repo)
  • Having separate issue trackers on GitHub means you don't have to start every issue with "In ..., this happens".

Upvotes: 2

Pierre-Louis Gottfrois
Pierre-Louis Gottfrois

Reputation: 17631

If you plan to re-use those separate "projects" you should use a git submodule. However if you don't, I would simply separate them in different folders under one unique git.

git submodules are great for projects that can be "cloned" and keep up to date in any other (bigger) projects.

Be aware that it is adding some complexity layer when dealing with submodules.

Upvotes: 2

murrekatt
murrekatt

Reputation: 6129

I would keep those as separate projects. If you need to combine git repos you can always use git submodules.

Upvotes: 0

Stefano Falasca
Stefano Falasca

Reputation: 9097

If the single modules are reasonably independent you can use git submodule to mingle the two approaches. You would end up with a single folder/repo in which a you have a folder for each sub-project. Every sub-project is a separate repository and can be used as such, but you would gain the ability to track the version of each project from the root repository as well as issuing "joint" commands to the sub-modules as in

git submodule update

or "recursive" commands, as in

git submodule foreach make

you find the documentation and some sort of tutorial online.

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

Upvotes: 3

Related Questions