Well, one thing you seem to be missing is, git is easily (I'd even say "normally") accessed via network protocols (choose http, ssh, or both), which saves you the "access to the file system" problems.
More precisely, you typically have one central git repo accessed and secured that way, and you build releases from that one. The git model also puts a complete repo at each developer's desk, which is where it gets most of its speed and branch-and-merge slickness. But you don't need to worry about securing these local repositories from developer mistakes, so long as you stick to the build-from-central model.
Developers develop in their local repositories, but push up to the central (causing their changes to appear in the central, but on a branch not the "master"). Then, they issue a "pull request," which means someone with suitable authority and testing responsibility merges the branch changes into the "master," whence they can be built and released.
If your release situation is complicated enough to need it, you can have separate branches in the central, say one for each release, all managed in the "master" way, and a plethora of developer branches, worked locally and pushed to central, then pulled to the appropriate release branch for build and release.