I'm trying to figure out the best use of Git for my development team. We work on multiple C projects that share some common modules, each one varying a bit in each project. A module can be a hardware driver, a sensor driver using a hardware driver, an algorithm library, a task using a library with a sensor module, etc.

That means that if a module is in both projectA and projectB, a developer of projectA might want to change a piece of code in this module, to propose this change to the library owner who will accept it, without that it directly changes the state of the module in projectB. Then, the developer of projectB might want, or not want, to update its module, as well as modifying it a bit to match his needs.

I've already read this Q/A but I am not sure it's the same scenario, I think that in this Q/A the author does not want to modify the module into projectA or projectB. Another difference with this Q/A is that I would really, really prefer if this was possible while having all my modules in the same repository (but the projects in different repositories). This is because we're working on embedded projects so our libraries cannot be really independent, they are organized by layers. It would seem crazy for us to have one repository per software module (sensor this, sensor that, algorithm this, algorithm that, task this, task that, hardware module this, hardware module that, etc).

I have also read this Q/A but I'm not sure if adding all the modules in one submodule allow a project developer to manage each module independently.

Would it be possible to work like this while having one big library/modules repository, and projects repositories ? If so how should we work ? Can we consider the projects as forks of the main modules collection repository or using it as a submodule is the way to go ?

Here is a schematic with what I'd like to achieve : Git organization

  • I'm thinking of using a single repo for multiple firmware projects, keeping them isolated from each other as branches, but allowing them to share changes, and using git-worktree to check them out at the same time.
    – endolith
    Jun 23, 2020 at 17:06

1 Answer 1


Basically if you accept a pull request from A and B don't want it, you can't distribute the same module. This means you need :

  1. The core module, which include everything that you develop for A & B
  2. A core's branch dedicated for A's specific
  3. A core's branche dedicated for B's specific

Another solution could be to use preprocessor's directive to isolate A's specific stuff and same for B but I'm not sure it's a good idea on the long run and it will increase the complexity of your module.

  • Thank you ! That means using the core module as a submodule would allow me, from a project using this submodule, to create a branch and modify it in the submodule's respository directly ?
    – Tim
    Nov 23, 2016 at 12:11
  • yes, furthermore with git you can create branch of branches, so you can easily branch any feature requested to isolate each of them independeantly. Of course this means the A & B's specific branch will need to receive the update from the core's main branch to stay uptodate.
    – Walfrat
    Nov 23, 2016 at 12:18
  • You should not have A and B as long running separate branches in the same repository. If they are essentially not the same any more they should be split apart. Apr 21, 2021 at 7:29
  • Well I wouldn't bother to maintain different repositories as long the A and B developpements are not big. However if they become big enough, that does make sense.
    – Walfrat
    Apr 21, 2021 at 8:12

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.