I have two libraries that implement a protocol: one provides tools for establishing a channel between two parts, and the other provides classes and tools for building and parsing the binary protocol messages.

These two libraries can be used independently, they don't depend on each other, and each has its own build setup. However, they do share a common set of examples (using both libraries) and documentation (tutorials).

I have two alternatives in mind for organizing this in Git repositories:

Alternative 1

Make each library be in its own repository. A central repository would keep the common documentation, examples and tools for cloning both repositories and bootstraping them. Users would use this main repository, and developers would work on the dedicated repositories.

I don't want to use Git submodules since they are hard to manage this way (versioning becomes much harder to do when the libraries constantly change).

Alternative 2

Place it all together: both libraries, documentation and examples. Versioning would be applied to both libraries, since they would be treated as a single (though separated) entity.

This is how we are doing it now. It makes things simpler but I feel it could be improved.

So... what are the best practices for organizing it all using Git? I'm open to other alternatives too.

Even though we're not using it right now, it's possible that we will be using continuous integration tools, automated testing and builds, etc.

  • Do the two projects have common build steps? Do they share a version number? For example, when library A has a release, library B does too?
    – user22815
    Apr 16, 2014 at 14:39
  • They have similar but independent build steps. Versioning is independent (but it might happen that both have a coordinated release). The project is now live and we have adopted alternative 1 (but I'm still open to opinions!): opennetworkingfoundation.github.io/libfluid
    – Allan
    Apr 17, 2014 at 0:58

1 Answer 1


Source code repositories (i.e. git or other vcs) should be organised for the convenience of those who work on the source code; fix, extend and release it.

Binary repositories (i.e. Debian, maven-based repositories, etc.) should be organised for the convenience of those who work with the libraries.

Sometimes, in the short term, you use the source code repository to deliver stuff to your end-users, just because anything else would be overkill. In that case, then by definition it's not worth reorganising things for their convenience; what you are doing is either too simple, or has too few end-users. If that changes, then set up a binary repository rather than reorganise.

As you say you want to version the two things together, that suggests a single repository. And it doesn't sound so big that you are hitting the point you want to split the repository for performance reasons.

  • I forgot to mention it will be an opensource project and I won't be shipping binaries. For developers it'll be better to work on the libraries separately (for commit messages, bug tracking and independent versioning). The question wasn't clear on this, but independent versiong would be better. People using the library (developers too) would benefit from having a single place to start when learning. Do you know any similar examples?
    – Allan
    Feb 15, 2014 at 14:44

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.