2

I'm working in an environment where the developers work directly with script and image files on the live deployment web server. This is scary and has caused a few, though so far surprisingly few, issues. Source control is not used at all for these changes, the changes are made on the live server and only on the live server. I don't know how to make it so that changes other developers have made on the live web server are kept/merged when I deploy my changes to the live web server. This issue would seem to make matters worse using source control rather than better.

I have personally setup git and svn servers, and used version control with git and svn for the past several years on many desktop app and mobile app projects. But this has me stumped.

Improve this question
4
  • When devs do stuff on live, they need to commit their fixes to the production branch directly, eventually merging or rebasing from new things that happened upstream. Would that be an option?
    – slhck
    Sep 3, 2014 at 14:03
  • No, I am not in a position of authority to instruct or make requests of the other devs. By the way source control is not used at all for these changes; the changes are made on the live server and only on the live server. I have updated my question to reflect this.
    – timeSmith
    Sep 4, 2014 at 14:51
  • Can you, during a deploy, first commit the local changes on live and then merge it with the production branch? It's quite a mess for every deploy, but I don't see any other way (not that experienced with Git though..)
    – slhck
    Sep 4, 2014 at 14:53
  • I don't know how to do that. I would if I could. The best thing along those lines that I've thought of is to copy all of the relevant files from the server to a local check out that I keep for that purpose, commit from that check out, pull to my checked out branch, merge, commit, and copy the result back to the server. But that seems really... well I'm hoping theres a better way.
    – timeSmith
    Sep 4, 2014 at 15:01

1 Answer 1

Reset to default
2

Best practice is to use git as part of how you deploy. So much so that you'll find relatively few answers about other uses of git.

That said, git can be used in many ways. If your deployment is to the live server, and not from git, then there's still value in committing changes to git, so you can at least see what changed when, and roll stuff back. What you'll lose is sensible comments and grouping of changes into commits so that you can see where you want to roll back to quickly, and you can see what changes in different files are likely to be dependent on each other.

It is perfectly possible to let your live code be a git working directory, and you can have automated updates of the repository running every so often from cron.

etckeeper (https://github.com/joeyh/etckeeper) is in some ways comparable. It's designed for recording changes in a server's /etc directory, as opposed to a web site, but it's otherwise quite similar to what you have in mind. It'll probably have some useful ideas tucked into it's commit hooks and the like, but it's also complicated by covering several different VCS systems, and compatibility with multiple operating systems.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .