5

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?

  • Please clarify what you mean by "However, when modifying the code shared between the different projects, I don't want to have to test it on every platform before pushing to the git repo as it would not scale at all." – Aaron Kurtzhals Aug 2 '13 at 20:35
  • I tried to make it clearer. Basically I don't want to have to test the code on each project hardware everytime I'm changing something in the shared code. – Étienne Aug 2 '13 at 20:40
  • Do you write any of the shared code, or is it only supplied from 3rd parties? – Aaron Kurtzhals Aug 2 '13 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 Aug 2 '13 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 Aug 2 '13 at 21:17
4

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 Aug 2 '13 at 21:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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