Complex Nested permissions (Groups?)

I am trying to port a really old flat file based game project over to gitlab while allowing our collaborators access similar to their access through the game’s interface… this creates a lot of smaller repos… However I am not seeing how Gitlab’s group/subgroup permission system might work in this case (it feels really backwards to me).

To simplify the description I will use numbers to represent the existing restrictions, we have two branches of 5, 10, 20, 30, 40 – basically one group can write to master, the other only to the dev branches of each.

Each step up in numerical value adds write access to at least one new micro repository (its split based on the fileystem paths of the game’s files)

To make this even more fun, 2 repo’s has additional level of granularity, meaning there are sub folders/repos under them that cannot be access until the next rank is given… ie: /this/path would be writable by level 10 but this/path/restricted may require level 20…

I’ve done a lot of reading on the sub groups and permissions but it seems each nested layer requires a repo to be created under it… am I misunderstanding this?

Please help me understand this seemingly convoluted system, I’d really love to get our project moved over but this has been stonewalling me for weeks now :frowning:

Thanks in advance!