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.

  • This still allows updates to be made that turn out to create conflicts when pushed to Git. If possible, I'd prefer to reverse things: everybody has to write to Git (and can't push until conflicts are resolved) and the web server uses data pulled from git. Commented Dec 8, 2016 at 18:58
  • 1
    You need to break yourself and your clients of the (bad) habit of making changes on a production server. Once you do that, it's relatively easy to auto-deploy from Git onto that server.
    – kdgregory
    Commented Dec 8, 2016 at 20:23
  • So the problem is with content maintainers, and several trusted business customers. Do they have access to the Git? Do they know how to use it? Another question is. What kind of static content do they change/upload that It's not (may be it should not be) in the Git? CMS exists for a well reason
    – Laiv
    Commented Dec 8, 2016 at 21:05
  • @Laiv You are correct, that is the problem. The maintainers have access to Git, and could be trained to use it, the business customers would not have access or know how to use it, or want to be trained. When they make changes it's to static html, or file uploads such as pdf/xls/docx/etc. Commented Dec 8, 2016 at 21:24
  • 1
    You could redirect ftp account to another folder. An specific workspace for example. The workspace be pointing to a specific branch of the Git. Then via servicies execute periodic pushes to the Git. Finally, an authorized user may perform the merge request into the "right branch" and build up the deployable ( a copy of the content into the webroot). All this magic is possible with CI tools too
    – Laiv
    Commented Dec 8, 2016 at 21:31

1 Answer 1


I would recommend that standard terminology be created, and that simple documentation authored, so that all stakeholders can agree to a policy.

There are (at least) two problems that need to be resolved. The first is, that the dynamic content is managed outside of the repository. So, you would like a solution, such that any dynamic content changes will be tracked in the repository. This could be accomplished through automation of repository commits of the dynamic content directories, on the production server. And, that could be implemented via periodic commits (eg. frequent cron jobs) or via triggers when an FTP upload completes.

The second problem is, that when the application code is committed by developers, and then subsequently pushed or deployed to the production server, the dynamic content can potentially be overwritten. The Git repository can handle this, by rejecting a push that has a dynamic content conflict (since the content is being tracked and would require the developer to pull/merge/resolve). Or, alternatively, the dynamic content directories can be added to the .gitignore file, so that a developer never commits any dynamic content files.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.