First the workflow:
You will need a server that will act as the central storage for the code and install appropriate system there (more on choice later). It will have to be accessible by everybody who need to modify code and for security reasons should be separate from your regular web server. Unless you really need to make it visible from the internet, don't.
On the web server, make the data directories checkouts from the version control system. There will be one checkout for each site and than one or multiple checkouts of the shared code. If you currently have the shared code on the server just once, you can go with one checkout now and switch to per-site checkouts when you get into situation that some site will need new code and another will need to stay on the old one.
Well, if the sites are simple or very closely related anyway, you can just have everything in one big checkout and one big working tree.
Arrange for some mechanism to update the web server when changes are pushed to the version control. You can have either manual or automatic process or combination thereof. I would suggest automatic process for updating the test environment (so you can review your changes immediately after pushing them in) and manual for updating the live one (so only reviewed changes get published).
In either case you'll have a script on the web server, that will run appropriate update command on all the checkouts. The script shall be started either by the web server (by accessing special URL) or by ssh trigger (special ssh key bound to run the specific command only). Than you can start it manually or from "post-commit" hook.
Everybody who will be making changes will check the parts they need to work on on their local computers. The layout will be the same as on the server, but if they never touch some site, they don't need to check it out.
Now to make a change, you'll run appropriate update
command on your local checkout, edit the files, test with your locally-installed web server if possible and commit and push to the central server. Trigger the update script on the test server if it's not done automatically and have the changes reviewed. When they are reviewed, you or the tester will trigger the update script on the live server, preferably explicitly telling it up to which version to update (the one reviewed).
The process should work as much the same as it does now except you'll use the version control system to deploy the files instead of whatever copying you are doing now.
"stepping on each other's toes":
Version control systems generally work with the "edit-merge-commit" cycle these days. That is you start editing the file and when you are satisfied with your modifications, you run a command to merge them with whatever other changes happened meanwhile and than commit the result.
The merge is a line-based text operation. It looks at what lines were added and removed (modify = remove + add) on each side and if the changes are to different parts of the file, it will apply both. If both modified the same part of the file, there is a conflict, which can be resolved using special editor that shows you all the versions and allows you to pick the version you want. There are e.g. kdiff3, meld and many other.
This simple approach works rather well for most kinds of files, but you should avoid unnecessary reformatting as it may cause conflicts. It however does not work for binary files, which includes images and video. There the version control tool will simply say the whole file is a conflict and you'll have to pick one or other version.
So if you happen to modify them a lot, you may want to use the "lock-edit-commit" cycle instead, i.e. the person wanting to modify such file will mark it as being edited and others will be told that they shouldn't touch it now. This is however only supported in centralized system. However in my experience those files are rarely modified by more than 1 person or with any significant frequency, so the very rare case of conflict simply isn't worth the extra work using the locks.
Choosing version control system:
The most modern and more flexible these days is distributed version control systems and of those the two most popular are git and mercurial. There are already some links to comparisons in comments, so I won't repeat them.
However if you happen to need locking, you'll have to use a centralized version control system. The most common option there is subversion. However it's branching support is really poor compared to git and mercurial and it's quite a bit slower. So only use if you really edit binary files a lot.
Note: Now I remember I worked with something that really needed the locking approach -- Adobe CreativeSuite 3 sources for Flash. I believe it's no longer such problem with the new tools, but we couldn't use that than, because it didn't support the Flash Lite target.