I have some code that uses a library that I and others frequently modify (usually only by adding functions and methods). We each keep a local fork of the library for our own use.

I also have a lot of small "driver" programs (~100 lines) that use the library and are used exclusively by me. Currently, I have both the driver programs and the library in the same repository, because I frequently make changes to both that are logically connected (adding a function to the library and then calling it).

I'd like to merge my fork of the library with my co-workers' forks, but I don't want the driver programs to be part of the merged library.

What's the best way to organize the git repositories for a large, shared library that needs to be merged frequently and a number of small programs that have changes that are connected to changes in the library?

2 Answers 2


Sounds like a good fit for git submodules - move the library into it's own, public repository, then add it as a git submodule to the repository where you keep your driver programs. If you haven't used git submodules, it might take some getting used to; understanding how it works requires some knowledge of git's internals. Here's a tutorial that I found useful.


You could make the library be one repository per developer, so each developer maintains their own fork but can pull from each other.

You could make the library be one shared repository such that commits that go to master are not expected to cause uncommunicated issues for the other developers.

Both of those have a slight complication in that given a version of a driver program it may be difficult to get back to the version of the library; you'd need to decide that's not a problem or start tracking what version your driver programs need.

The other main solution is to do nothing, but as you've seen git isn't well-suited to treating part of a repository as a whole, unlike its centralised slightly cumbersome cousin Subversion.

More specific answers might depend on knowing what language the library and client programs are written in.

  • It's C++, and for the most part we only add functions and methods to the library, so breaking compatibility with driver programs shouldn't be a problem.
    – Dan
    Oct 10, 2012 at 0:05
  • 1
    Another problem is that the forks haven't been merged in ~4 years.
    – Dan
    Oct 10, 2012 at 0:06

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.