Don't deploy prod from the repository
There should not be a "production solution" in the repository. There shouldn't even be a production configuration file in the repository. The development repository is not the correct place to store production configuration, like the server addresses or the credentials necessary to access them.
In fact, your production deployment process should not involve Visual Studio at all. I know Visual Studio gives you deployment features built in, but they are not worth using because of the problem you're having now. These features should only be considered for toy projects.
Your production deployment process ideally involves taking a fully built artifact and deploying it, either manually or automatically with devops tools (like Ansible, Chef, or Puppet). It might be an installer, or it might be a zip file with the binaries and some scripts inside. Whatever it is, it's a final product built from a well established (and preferably automated) process that isproduces an artifact completely segregated from the repository itself. The app itself should be looking to environment variables for any potentially sensitive configuration parameters, such as database credentials, rather than on-disk configuration files that are part of the repository.
The only thing the developer should be deploying from the repository is their own personal development environment. Ideally, each developer has their own copy of the database on their own local machine. Then they can freely create, modify, and delete it at will. Yes, this means they need to install the database server on their local machine or in a Docker image or something of the sort. You should only consider having devs use non-local database servers if licensing makes it unreasonably costly or difficult to install on their machines, and even then they should have the ability to manage personal development copies of the database on the server that are clearly segregated from production and even any centralized testing deployments. Everything except the developer's personal environment should be deployed using the same process as production, using the artifact and the deployment steps designed for it but with different environment settings.
It's okay to take this one step at a time instead of going whole hog. The first step is just get the production set up out of the repository and start deploying it using a build artifact. Once you do that, you open the door to moving more in this direction.
Protect production
The production environment should have very tightly controlled access. Only individuals trusted to follow the process should have access to the credentials necessary to perform deployment there. In medium or larger organizations, they might not even be developers, although they will need to work with devs.
The credentials should also be given minimal privileges. The ones used by the application to read and write data to the database should not have permissions to modify the database schema; that should be done only by a user with higher privileges during deployment. (Developers do not necessarily need a lower privilege user to connect their local build of the app to their personal disposable copies of the database. It's not a big deal if they need to recreate it after making a mistake; that's half the point of making it easy to create and update it.)
As noted by other users, you should leverage your database's built in backup/restore technologytechnologies, as well, whatever that happensthey happen to be.