Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Best way to handle multiple repositories - submodules, monorepo, or the third way?

Dmitry Linov
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
Nov 06, 2020

Many of us are familiar with the case when a project consists of several cross-used repositories (e.g., two apps and a shared library). The native Git way to handle this situation is Git Submodules, but they are not very convenient to use, to say the least. The most popular approach today is to put everything in one large monorepository, but it also has significant shortcomings (well described here). I've even met people who refuse to migrate from SVN to Git mostly because they can't imagine their life without svn:externals.

We at TMate Software have faced this problem a while ago and ended up devising a third way. We made a server-side tool that creates a directory in one repository, synchronized with another repository. All syncing is done on the server - for the end-user, it's still one regular Git repository, no need to run any special commands or push to external repositories separately. We called it 'Git X-Modules'.

We've been using this for almost a year, and it seems to do the trick. So, now you can try it out at the Marketplace.

What do you think of such an approach? Have we missed something important? For what workflows it won't fit?



Log in or Sign up to comment
AUG Leaders

Atlassian Community Events