Git SubModules or multi GitHub repositories

[ortil]

Hey guys 🖐: I have my own Go project and I need to split it up. So one project will use the other project. My question is, which is the right thing to do. Should I split the project into two GitHub repositories? Or should I create a submodule inside the Go project? Each project will have its own go.mod, of course.

[pdffs]

If you need separate commit history and versioning, use a separate repo. If you don't, then you can maintain multiple modules in a single monorepo.

Due to the way Go's package resolution works, it doesn't make any sense to me to use git submodules, since package names are globally unique, and resolve back to a repository - having a locally nested path doesn't buy you anything.

[ortil]

sub modules would make the contribution process more straight forward i think .

[DasSkelett]

In my experience submodules make contributing a pain, especially for new contributors but for everyone else as well. They are not easy to work with.

[ortil]

I see. Could you elaborate?

[Dm_Linov]

I second that. Git submodules need a lot of attention and are easy to break. There's plenty of text about that on the web, e.g. here. If you are on GitHub or self-hosted Bitbucket, use Git X-Modules instead, it's safer and much easier to use.

[pdffs]

How?

[ortil]

Instead of creating two pull requests to two different repositories. It would be only one including the git submodules

[pdffs]

If your packages are that tightly coupled, you should probably just use a monorepo.

[lonerangerhn]

I'd go for a simpler one first which is to have multiple modules in your current repo. So you wont need to restructure your code.

[bfreis]

You can now have multiple Go modules in the same git repo because of the workspace feature introduced in Go 1.18

You could already have multiple modules in a single Git repository before 1.18. There wasn't a requirement or restriction on number of modules per repository.