2

Currently, everything that is in the public_html folder automatically gets published live. The git repository is also inited in this folder (though this can change if it's necessary).

What is a good git workflow/set up such that my changes are only published when I do a git push, instead of automatically whenever I do a write to disk?

Ideally, I would have one or more branches as a development branch, and one for a stable branch (per standard git work flow). But if I create 2 branches in the public_html directory, my server will publish whatever branch I am on.

Should I create a mirror directory, and connect it to the same git repo, and limit one to pull access, while the other one has push and pull access?

Any suggestions would be great.

Improve this question
3
  • 2
    Do not edit your site on the production server! Edit it locally, then when you want to release it make the server up to date.
    – RemcoGerlich
    Commented Feb 25, 2016 at 8:30
  • my only environment right now is the server (I SSH into it and edit remotely). I'm hesitant to do it locally because then every time i'm done editing locally, I would have to scp the files over, and would prefer to avoid that if possible. Is there another way?
    – bluejay5
    Commented Feb 25, 2016 at 8:45
  • Editing locally is about not breaking the production site every time you want to fiddle with something. It's definitely worth a modicum of inconvenience, unless your employer really does not care about stability at all (which seems unlikely). That said, deployment should be automated as much as possible (again, for reliability), and if it's as simple as scp'ing a bunch of files from your machine to the prod server it shouldn't be too hard to whip up a script to automate that.
    – Ixrec
    Commented Feb 25, 2016 at 9:12

1 Answer 1

Reset to default
3

First of all, you should really not develop on the server. Unless you have a very complicated server, I think you should be able to set up a local "server". This is not that hard to do, either using:

  • your local machine as server,
  • a virtual machine (VM) (see e.g. Vagrant),
  • a container (see Docker).

The advantage of a VM or container is that this can be ported more easily to other developers or when you change computers. Also, if you have multiple projects with different technologies, this avoid having multiple (conflicting?) servers running on your machine all the time.

Now on to the actual question. There are a few options that I see. The easiest solution was already suggested in the comments:

  • just write a script to scp/rsync/... over your files to your server. This doesn't take longer than running a git push and the script is probably just a single line.

If you really want to use git push for this, I would recommend the following:

  • make sure your server acts as a git server and set up a hook for post-receive. The latter could be a script that just checks out the current master branch to your public_html directory or something like that.

There are quite a bit of more advanced options, e.g.

  • if you already have a Continuous Integration (CI) server such as Jenkins, there are plugins that help to publish your website after passing all tests (by running a script, copying the files, ...). So this is obviously the more robust choice, but setting up Jenkins can be daunting at first (there are other providers of CI software, though).
Improve this answer
1
  • 1
    If you choose the last option —having the continuous integration automatically deploy the revisions (only of a selected branch, usually) if they pass all tests— you already have a simple form of continuous deployment.
    – das-g
    Commented Feb 25, 2016 at 15:05

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.