Git Architecture – Organizing a Git Repository with Shared Code Projects

Architecturegit

I have several small projects running on different embedded hardware, and about 50% of their code is identical (typically some drivers, their operating system, and some libraries).

I want to merge those small projects into a single git repository so that it becomes easier to centrally maintain them, for example to update a driver.

However, when modifying the code shared between the different projects, let's say a driver, I don't want to have to test it on every hardware platform before pushing to the git repo. It would not scale at all as to test the code for a given project I have to test it on a specific per-project hardware and if necessary correct the project-specific bugs which could be introduced by the modification of the shared code. It is a lot better to delay the testing of the shared-code modification on a given project the next time I want to modify this project.

At the moment, here is the solution I came with:
the directory structure would be as such:

                 .
                 |--shared_code
                 |--projects
                    |--projectA
                    |--projectB                       
                    |--projectC

I would create a git branch per project, which would only represent until which commit the code was tested for a given project. Hence I would push code only to the master branch, and merge the code from the master branch to a project branch once it has been tested on this platform. Like this a project branch would always be in a stable (tested) state. The master branch would be unstable for most of the projects.

git structure:

                                             master
                                               |
  commits: 1 <-- 2 <-- 3 <-- 4 <-- 5 <-- 6 <-- 7
                 ^     ^                       ^
                 |     |                       | 
  branches:      A     B                       C

Is this the correct way to solve this problem? Is there a better solution?

Best Answer

I would suggest to keep the shared code in its own repository, and projects in its own as well.

I suggest keeping stable code in master, and unstable code in branches.

For the shared code repo, I suggest making a branch for each project as needed. When you have tested code on all projects, merge to main.

I think it would be confusing to try to manage all projects together in the same repo.

Related Topic