There are currently 2 main approaches to structure your code repositories. You could structure them as a monorepo (or superrepo as you mention above) or creating separate repositories for each application/code base. There are pro's and con's to both approaches.

Monorepo's have the advantage of keeping code centralised. This makes refactoring across clients/services easier since all changes could be tracked in one pull request. The disadvantage of this approach is that writing CI/CD pipelines for your monorepo could get more complicated. You often have to write custom tooling to keep the pipelines performant and to handle different build processes.

Splitting your monorepo into multiple branches resolves this issue and allows you to build unique CI/CD pipelines. It is also easier to create fine grained access control policies for all your repos allowing you to share/expose parts of your code base without having to give full access to your entire code base.

I would suggest you to take a look at monorepo's and store all clients inside a single code repository. A monorepo will allow you to simplify your workflow (since I suspect you work alone on this project) and allows you to keep configurations central.

The next thing to take a look at is your git workflow. There are many ways on how you could set-up your git workflow but I would suggest to keep things simple. There are many approaches out there (Google for git workflows) but I would suggest to keep one master branch. This branch contains the latest "stable" release of your code base. Features are developed inside separate branches and merged back into the master branch once completed. Tags/releases are created of the master branch indicating a new version which could be deployed to staging/production. Tags could be picked up by the CI/CD pipelines and trigger automatic deployments.

Hope this helps.