Question About Repository Structure Patterns

I’m have been looking into refactoring the repository structure of a project I’m working on. It’s a bit of a mess. We do not use any modules. Also, the Production and Development environments are long-lived branches, which leads to drifts quite easily, and the repository structure is also very disorganized. There are some stuff that should be in different workspaces also, and not on the same one together.

If I go with an approach where each environment is a different workspace tied to a different directory on the same branch. Something like this:

├── environments
│   ├── development
│   │   ├── scopeA
│   │   ├── scopeB
│   │   └── scopeC
│   └── production
│       ├── scopeA
│       ├── scopeB
│       └── scopeC
├── global
│   └── rancher
└── modules
    ├── scopeA
    ├── scopeB
    ├── scopeC
    │   ├── network
    │   └── rds
    └── utils

In which I have 7 different workspaces:

global-workspace → global/
scopeA-dev-workspace → environments/development/scopeA/
scopeB-dev-workspace → environments/development/scopeB/
scopeC-dev-workspace → environments/development/scopeC/
scopeA-prod-workspace → environments/production/scopeA/
scopeB-prod-workspace → environments/production/scopeB/
scopeC-prod-workspace → environments/production/scopeC/

Then, for example, let’s say scopeC-dev-workspace and scopeC-prod-workspace use the same modules/scopeC/network module.

How would I perform changes on the module and propagate it only to scopeC-dev-workspace before I apply these changes on the scopeC-prod-workspace? Is this strategy that I chose for my repository structure any good at all?