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:


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:

  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?

  • Do you write any of the shared code, or is it only supplied from 3rd parties? Commented Aug 2, 2013 at 20:56
  • I write the drivers and some of the libraries, the OS (a very light weight one for embedded systems, therefore without any drivers) and some other libraries are supplied by third parties.
    – Étienne
    Commented Aug 2, 2013 at 20:58
  • Did you take a look to [gits submodules}(git-scm.com/book/en/Git-Tools-Submodules)? You could create a big project, the shared code and all projects buils there own submodules. (I'm not familiar with submodules, so I can't give you a real answer).
    – knut
    Commented Aug 2, 2013 at 21:17
  • 1
    Thanks for the link, I think it could work, but the workflow seems quite complicated to me.
    – Étienne
    Commented Aug 2, 2013 at 21:59

1 Answer 1


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.

  • Thank you for your answer! I think you're right that I should keep several repositories. The problem with having the stable code in master in my case is if I'm not working on a given project any more the changes in the shared code will never be merged to master since I will never test the changes on this specific project.
    – Étienne
    Commented Aug 2, 2013 at 21:21
  • 1
    How would you physically structure this on disk? Currently for my (also embedded) projects, the code that's common between projects and the code that's unique for each project are in the same folder, and I don't think there's any way for two repos to share the same folder. I've also considered using preprocessor instructions to mask out project-specific sections of code, but that could become very unreadable quickly. Maybe if I restructure the manufacturer's code to compartmentalize more things into functions that could work. Or separate different projects better into separate .c files.
    – endolith
    Commented May 12, 2022 at 21:30
  • Perhaps this question helps, @endolith : stackoverflow.com/questions/2896944/…
    – Sam Sirry
    Commented Dec 6, 2022 at 4:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.