Multiple git repositories with a common core lib

Question

I have several git repositories for a web project that share a library of common code. I don't want to repeat the common code inside for each repo. What are some ways others have solved this problem?

Git submodules seem to get a lot of hate because they tend to cause more problems than they solve

I could just have a separate repository for the core lib, but then there would be no way for matching versions if the repositories are being developed by separate teams. (For example, if v1.0.2 in a repository requires v2.0.0 in the core lib, that information should be tracked somewhere).

In Android, build.gradle more or less solves this problem. Is there something similar for git? For example:

compile 'com.android.support:appcompat-v7:25.0.1' refers to a specific version of a remote dependency. (Source: Android docs)

Answer 1

You can treat the shared code like code or like a package. If you treat it like code, then git submodules is the right answer. If you want to treat it like a package, you need to introduce package management as part of your development process.

You may already be using a package manager like maven, nuget or npm to incorporate third-party packages into your projects. The idea is to publish your shared code to a package repository you control (there are both free and commercial package repositories available for these package systems); your developers who use the shared code can then incorporate it into their projects much as they would a third-party package; this provides the version-tracking functionality you require.

Treating the shared code like a package does incur some overhead and might not be worthwhile if the shared code is used by few clients. But once you start to have more client projects for the shared code, each with independent release schedules, treating the shared code like a package becomes more appealing.