Reducing Boilerplate Between Repositories

Generally, it is a smart architectural decision to split a system into smaller pieces. It could be migrating a monolith to services or moving some functionality into a library.

For each of these situations, you might create a new repository. But with current tools, there are some disadvantages. Increasing the number of repositories also increases the amount of duplicate boilerplate. Boilerplate is configurations, scripts, or anything else that is not unique to that particular repository.

For example, imagine you’re on a medium-sized engineering team, and together you manage a web application and its services. There are also some custom libraries. Everything has its own git repository; there are 42 in total. The team has agreed to specific compiler settings and wants them to apply everywhere.

When someone creates a new repository, they manually copy the settings from an existing repository. It isn’t too big of an annoyance and takes only a few minutes. Everything is good, for a while at least.

But there is more pain hidden and waiting. When you make changes to a repository’s boilerplate, you must decide: do you change only that…