The answer to your problem is twofold.
TL;DR: Use DTAP and implement a VCS.
Firstly, in an enterprise environment you never want to be coding directly on the server. Even if it's not the live environment, having multiple people editing files on the same environment gives you a very high chance of conflicting changes, which leads to unpredictable results. Fully implementing DTAP will help you solve this problem.
DTAP stands for "Development, Test, Acceptance, Production" and is used to describe a system where you have 4 separate locations where the code can be. The separation is designed to protect Production from as many possible issues as possible:
First the code is run and tested on Development (which can be a separate machine but is often simply the developer's own PC).
If the developer is satisfied with his work, the code moves on to the Test environment, where someone else (ideally a dedicated tester but another developer can work) will try the code out.
If this phase of testing finds no issues, the code moves on to Acceptance, where the "business" side of the company will test the code. This can be your customer if your company makes a product for another party, or it can be a different department that is in touch with what the product should do in order to match the end-customers' needs.
Only if they accept the code will the code move on to the Production environment, which is the live environment.
Secondly, to keep track of the changes and to prevent problems that arise when multiple people modify the same area of the code at the same time, you should implement a VCS (Version Control System) in your organisation that will keep track of all the changes to all the files (examples are SVN, Git and Mercurial). These systems will also allow you to roll back changes if it turns out you made a mistake. To make life easier, it might be worth using your system of choice with an account at a service like Bitbucket which will allow you to use their interface for the process of combining one developer's work with another. All of your developers will have to agree on the specific strategy to use for merging the code into the state that will be moving on from development to the next environment, but I won't overload my answer with that.
When you say that non-technical people are modifying the test environment, I hope you mean they do changes to the configuration and/or content, not to actual files. Non-technical people should never be touching the code of the website, after all if they have no idea what they are doing they might accidentally break something!
With regards to the issue of compatibility and the statement that non-technical people cannot be expected to maintain their own Apache server, there are several options I can see. One option is to have one person manage the installation of these servers for all the parties involved, but this can be a full-time job and it might not fit your organisation to have such a person. The alternative is to use one of the available tools like Vagrant or Docker, which will allow one technical person to create an "image" that will have the working environment (which will typically be Linux based) and that image can be distributed to all the developers so they can run it on their own machine. If updates to the architecture need to be done, this person updates the image, and distributes it to the developers again.
From the original post I infer that your company is past the state of "only 2 people are working on the site anyways so it doesn't matter what we do". These concepts I propose are widely accepted as good practices, as you can see from my explanation you will gain a LOT of added checks of the quality of the product, at the tradeoff of introducing some relatively slight additional complexity to your process. A version control system like Git or Mercurial may seem intimidating, but in my opinion, with some training literally anyone can learn how to work with it properly. All it requires is an attitude of willingness to learn instead of seeing the system like an enemy that is preventing you from getting your work done, the latter of which is sadly a lot more common than it should be. By learning how to use the tool properly, you are saving yourself the time that you would have to spend on correcting mistakes and manually sorting out how the work from multiple people should be combined into the code.