Sharing code between two projects in git

Question

I have two closely related projects (A and B) that contain some source code (S). Both will be released at the same time, and the released version should always use the same version of the common code. Common S code will change often enough.

So it will look something like this:

• Version 1 uses S version 1
• Version 1 uses S version 1
• Version 2 uses S version 2
• Version 2 uses S version 2

What is the best way to handle this with git (and / or some tools that use git)?

Here are my problems:

• Project A and Project B should be in separate repositories (they are connected, but I do not want to have a free code flow between them). A.
• If the common code is updated in one project, it should be automatically updated in another (I do not want to have a situation where the developer forgot to do something and ended up being outdated on the version of the common code).

As I understand it, one of the canonical answers is to use the git submodule . However, I read some criticism about this approach. I felt it was more for shared libraries, which rarely change.

Another approach I read was to use git subtree

And there are several less popular approaches: Repo , GitSlave

What would be the best approach to handle this type of code sharing?

Answer 1

A very simple solution would be to use three repositories: A, B and S. Project repositories A and B would check their Makefiles to make sure that the developer uses the latest code pushed to the repository, for example

check: git fetch /path/to/S master:tip git branch --contains tip | grep -q master 

The second line will have a nonzero return value if the developer has an old version of the shared repository. This will cancel the compilation with an error. Then the developer can go and pull the repository manually to continue.

Instead of checking the main S branch, you can also check for any other branch, which is defined as always by the one that developers should use.