Consider a bitbucket project with 3 separate repos, A, B, C. These form the components of a microservices application, APP. We'd like to safely try out a monorepo pattern and see if it streamlines the codereview/deployment process. Ideally these would be replaced by a single repository APP that has subrepos (or modules) A, B, C.

 - A
 - B
 - C

However, we need to do this in a safe way such that the existing repos are migrated one at at a time, or even better, are still independently operable (ie. there is both repo A and monorepo component A at same time.

So my biggest fear is that I do this wrong and brick our repos. To avoid this, I've theorized some approaches:

1.  Fork each repo (A,B,C) and add the forks to the monorepo - keeping dual complete separation and duplication.  We would then migrate development incrementally into monorepo, service-by-service.
2.  Some magical git settings that would push commits to two places on the remote?  Both to the standalone repo and to the monorepo?  Then we could create the entier monorepo in bitbucket, update our remotes, and have changes go to both places as a pilot.

Whateve the solution, our build system is tied to the individual repos, so we have to do the migration gradually (service-by-service). There's no way we could setup this monorepo, and "switch over" in one blast. In reality, there are 40 or so services and its too risky.

Anyone ever done this or have suggestions?

2 Answers 2


There's another way to do achieve the same, without actually building the monorepo (keeping the original repositories intact). Create a new bare repository ('parent'), then add A, B and C as X-Modules (directories, synced with remote repositories), and work with that new repository as with a regular one. This way you can update all your remote repositories with one push to the parent repository. There's a special app for Bitbucket Server for that. And here's an article that describes the build process.

  • Ok thanks will def look into this! Dec 8, 2020 at 14:34

I've done something similar in the past, when Yarn came out, and there wasn't yet practical support for monorepos or private registries, in a situation where there was a main monolith application, and a big tendency to copy/paste working code between different repositories.

What I would recommend is to first prepare each repo by modularizing the codebase therein, aggressively extracting packages within those repositories, as if the intent was to be able to publish those independently to a registry.

You can then either subtree-merge in packages from other repositories slowly into your elected monorepo, obviously focusing on those packages that have no dependencies, until you fold all the repositories.

Alternatively, a better approach would be to create a private registry to redistribute these from, especially if you believe you might want to use these packages in multiple repositories in the future. While this might sound it requires more tooling and infrastructure, you can immediately decouple packages by mediate through the shared registry, and then subtree-merge at your own pace.

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.