Our organization currently has several web applications running on lamp servers. They are mostly static content, but also include php via codeigniter / laravel / vanilla php.
Whenever we make changes to any of the files we will update a git repository on a separate server to track that change. However, we also have content maintainers, and several trusted business customers that will update static content on pages and ftp those changes to the production server without committing to git.
As you can imagine this can be quite confusing at times, and conflicts happen often where one individual will pull the latest repo down thinking that the changes are current, make their update, push the file to production, and then 15 - 20 minutes later we get phone calls because they had overwritten changes that were not tracked in the repo.
I have been considering what to do about this dilemma, and have come to the following conclusion. We need to have a production repository configured on the production box, outside of the webroot (so that it is not publicly accessible), and create a service that will commit anytime a file has been uploaded to the server. This service could be written to alert an administrator if/when conflicts arise, and push changes to a remote repo on a timeframe (hourly/nightly/weekly/etc).
My question is...does this sound reasonable? Is there a better way to go about accomplishing this task? I understand and agree completely that the ideal resolution would be to only allow changes to production to be made via a hook fired when a commit is made to the repo and force users to learn Git (or another deployment tool that integrates Git), however this is not an option.