Manage versions of product consisting of several modules in git

We are currently using SVN for version control of both software and hardware modules that together form a single product. For this purpose, we have come up with the following structure (minimal example):

modules/
   |
   |- PCB Design
   |    |- tags
   |    |   |- 0.1
   |    |   |- 0.2
   |    |   \- 0.3
   |    |- branches
   |    \- trunk
   |- VHDL
   |    |- tags
   |    |   |- 0.1
   |    |   |- 0.2
   |    |   \- 0.3
   |    |- branches
   |    \- trunk
   \- Firmware
        |- tags
        |   |- 0.1
        |   |- 0.2
        |   \- 0.3
        |- branches
        \- trunk

products/
   |
   |- Variant A
   |    |- V1
   |    \- V2
   |
   \- Variant B
        |- V1
        |- V2
        \- V3

The idea is that e.g. "Variant A/V2" refers to a collection of versions of the different modules (e.g. PCB v0.3, VHDL v0.2 and Firmware v0.3). With svn, since everything (labels, branches) is a directory, this can be accomplished by using the shallow copy behaviour of subversion:

svn cp modules/PCB Design/0.3 products/Variant A/V2
svn cp modules/VHDL/0.2 products/Variant A/V2
svn cp modules/Firmware/0.3 products/Variant A/V2

Actual development would never take place inside "products", only in "modules".

However, this way of working is very SVN oriented, and we are looking for something similar in git. I've checked out submodules, but find mostly warnings not to use them, and subtrees, which don't feel like a good fit for this problem.

Are there other approaches with Git that can replicate something similar to this?

Solution

In your particular case I would presume that the changes stored in PCB/VHDL/Firmware are all completely independent of each other, and further that the group of people working in those repositories is all unique as well?

If so then I would guess that submodules wouldn't be nearly as bad for you as it is generally (additionally, submodule support has gotten a lot better over the years, so depending on what you read it may refer to an older implementation, which were admittedly poor).

Your ASIC guys would just be working in their VHDL repo as a single repo, and they wouldn't have to know about submodules at all.

Same with your EEs who would do their PCB layout in the PCB repo directly.

And your software engineers would do their work in the Firmware repo.

You'd only need a superproject (which had all those as submodules) for actually tagging a release as a collection of those 3 modules, and only the Project Manager would need to use it.