We have inherited an application that is made up of small .NET web API's. Each API has its own Visual Studio SLN and git repo. All of the APIs are published to one folder ("All") and that folder is hosted on IIS with each of the APIs as a separate application on the same website and app pool. The folder with the published APIs also has a git repo.
The one exception is the 'CommonOps', which is a class library that all other APIs share. The dll is published into a common folder.
Everything works for the most part, and I don't want to create unnecessary work (or update for update's sake).
The problem is when we find a bug. For instance, if something in the CommonOps needs updating, we need to create a branch in both, the CommonOps and the "All" repo. Then publish the updated CommonOps (pull request and merge), to "All" and then pull request and merge "All". If other people work on "All" at the same time, pull requests can lead to marathon merge conflicts.
What would be the best approach to unifying the whole lot into one repo, or should I leave well enough alone? If the latter, what would work best for a workflow when we need to change one of the APIs?