If I got you right, I see one major issue in your team's workflow:
You are using Git for deployment directly.
That is not what version control systems like Git are designed for, and even if a checkout from Git is part of a deployment, Git alone is typically not the only tool you will need for a working deployment process.
Here is a better way: your team could have something like a deployment script which copies every required artifact - but not the configuration files - from the dev environment into another environment (like your test environment, or later to production). That script could also stop the server beforehand and restart it afterwards, or do other things which are required for deploying, but which cannot be done by Git directly. And it should never ever overwrite environment specific config files.
Now, whenever you want to test a specific branch from the source tree, you use Git first to get that branch into your own local copy of the dev environment, including the developer's config files. Then you run the script for deploying the app from there to the test environment (and not changing the config there).
Note this approach assumes you already have everything which is environment dependent in a separate config file. Things like "the word Test written on the home page" should not be hardcoded in the source code, it should be configurable in some config file as well as the other things you mentioned.
If you like, you can manage your version of the test environment config files in Git as well. This could be done either in a separate repo, or in the same repo where the app is stored, but not in the real config folder. Instead, use a different folder named, for example, TestConfigFiles
. The deployment script then could just take the files from there and put them in place (or you do this manually, to make sure this does not get mixed up when deploying to the production environment).