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?
