It's impossible to make this call without understanding the differences between Client A and B.
If A and B have identical needs that will always be identical it's silly to make two copies of the things that fulfill those needs.
If A and B have different needs that need to fulfilled by different things then sharing those things gets you nothing.
But, if like most times I've had to do this A and B have some needs in each category, the important thing is how well you feel you can predict which will be which.
If you can clearly identify what will be the same and used by both you can create a library with it's own repo for both clients to share.
If you can't clearly predict what will be the same it's best to ensure A and B know as little about what is fulfilling their needs as possible. This lets you pass in what they need. This can be done in one repository. Sometimes the only difference is the construction that happens in main(), usually if you use those parametrizations you were talking about to change what fulfills what.
Any way you do it, the important bit is that the people doing development have clear territory to work in. You've been very "client A" focused. You're organizing principle has been upended. You need a new one. Don't try to get back your single client focus. Look at the whole problem and organize around it. Separate what will need to change from what will stay the same. This might require reorganizing the team. But I caution against creating a client A team and a client B team. Everyone will just fall back into their single client focus and ignore the other teams problems. That only works if client A and B share practically nothing. Or if what they share is maintained in some 3rd repo.
Instead you can mark out the work that needs to be done do deal with any number of clients. You have spread the assumption that Client A was the only client around. Now it's time to go uproot that assumption and make the code as client agnostic as you can. Do that work before you even add Client B and adding it will be much easier.
It's easy to over engineer this kind of effort. Don't make wild assumptions about what Client C will be and try to fulfill it's needs before you know what they are. Increase the proportion of code you have that doesn't know or care which client you have.
Now something, somewhere is going to know and care which client is which. Separate that code. Use it to hide direct knowledge of the client from the rest of the code. Isolate it, keep it small, and new clients will force you to change less code.
