How to handle many small repos?

I read that it is best practice in go to have one module per git repo.

This means I will have many small repos.

Changes will sometimes span several git repos.

How do you handle this?

The tools I used up to now (Github, Gitlab) only support pull-requests for a single git repo.

If I understand correctly, it’s not just a convention, but it is more a technical limitation.

Though why does that require many small repositories?

You can have many packages in your module and make it as huge as you need.

1 Like

Yeah - adding to what NobbZ said, I think there is confusion about modules vs packages. I have a monolithic module for one of my current projects, which contains several packages. Let’s pretend we have an integration service with a single module: github.com/DeanPDX/integration-service. And in this service, we want to provide integrations for smtp, http, ftp and so forth but we want those to all be separate packages. My project structure might look like this:

/integration-service
 - main.go // Might use /cmd/ subfolder if repo contains multiple runtimes
 /smtp // Package that handles smtp integration
 /http // Package that handles http integration
 /ftp // Package that handles ftp integration

To my eye, the separation of duties/code is very clear. We have small packages that comprise a larger module, which encourages re-use of these packages. Hope this helps.

3 Likes

Hi Dean, thank you for elaborating this. Makes sense.

Put everything in one repo. You don’t need more than one module.

1 Like

Do workspaces come to any use?

workspaces help to mitigate the problems of working with lots of repos.
But it is much better to avoid this problem in the first place…

1 Like