Robert Važan

Git repository granularity

How big should a Git repository be? Repository size may seem like a matter of personal taste, but it actually has a huge impact on development and release workflow. I have a lot of repositories of varying size and purpose, so I researched this a bit and here's what I found.

The primary constraint on repository size comes from shared repository-wide resources:

Okay, those are constraints we can use to evaluate any given repository granularity, but what granularities can we choose from? As I see it, there are three basic choices:

These three basic choices can be interpolated by choosing between in-tree development and separate repository for every component. So tightly coupled components, for example add-ons enabled by default in the app, would be developed in-tree while experimental and third-party add-ons get their own repository. Things get even more complicated with large files and unruly developers, both of which might be better off isolated in separate repos.

There is no one perfect solution. Choice of repository granularity has to take into account nature of the project, development workflow, tooling, and interaction with users, clients, and contributors. If I am to make a generalization from all of this, I would say that repository is a unit of sharing. It's not a matter of what is in the repository but rather of who is working on it. Repository granularity should match granularity of sharing, teams, and community.