10

I'm trying to decide whether moving to VCS is sensible for me. I am a single web developer in a small organisation (5 people). I'm thinking of VCS (Git) for these reasons: version control, offsite backup, centralised code repository (can access from home).

At the moment I work on a live server generally. I FTP in, make my edits and save them, then reupload and refresh. The edits are usually to theme/plugin files for CMSes (e.g. concrete5 or Wordpress). This works well but provides no backup and no version control.

I'm wondering how best to integrate VCS into this procedure. I would envisage setting up a Git server on the company's web server, but I'm not clear how to push changes out to client accounts (usually VPSes on the same server) - at the moment I simply log into SFTP with their details and make the changes directly.

I'm also not sure what would sensibly represent a repository - would each client's website get their own one?

Any insights or experience would be really helpful. I don't think I need the full power of Git by any means, but basic version control and de facto cloud access would be really useful.

EDIT: I've narrowed it down to the two options that seem most sensible. The first is based on ZweiBlumen's answer, whereby edits are made on the live server and committed from there to the (external) Git server. This has the advantage that my workflow won't change much (there's the extra step of making the commits, but otherwise it's identical).

The second option is to work locally using XAMPP, then to commit changes from the local machine. Only when the site goes live do I upload the finished article to the web server from the local machine (immediately after the final commit to Git). This seems okay in theory, but if the site thereafter requires amends and I make them on the live server (as I usually do) then I'll need to manually copy over the changed files in my local repo, then commit those changes to the Git server. This seems unduly complex and is perhaps too much of a departure from my current workflow.

I think on balance I'll give option #1 a go, and see how I get on.

Improve this question
2
  • 1
    The thing to remember about git (or any other distributed VCS) is that all repositories are, at least technically, peers: your local repository is just as "real" as the one on the live server, or the backup repository. It's your workflow policies that give them structure -- so if you really want to keep doing primary work on the live server, you can...
    – comingstorm
    Commented Mar 27, 2012 at 21:01
  • Thanks, that's good to know. The inherent flexibility of Git makes it hard to work out a 'best practice' starting point - that's a strength from an experienced user's POV but arguable a weakness from a noob's!
    – melat0nin
    Commented Mar 27, 2012 at 21:14

3 Answers 3

Reset to default
3

What I do (with Subversion, but will work with Git as well) is commit everything to one Subversion repository, but obviously split into projects, branches, tags as necessary. I then checkout these repositories to the live server. Thus when I make a change on my dev machine and commit this to the repository, it is often simply a case of updating the checked out copy on the live server to make the changes live. The added bonus is that if I do need to make a quick fix on the live server I commit this to the repository from the server and update the working copy on my dev machine.

I am sure there are other ways of managing this, but I find this quite straightforward and I am in exactly the same situation as you: single developer in a small organisation (4 people).

Improve this answer
5
  • 1
    Thanks for your reply! Does that mean you pull the snapshot to your local machine, make and commit changes, then do a pull request from the live server (by SSHing in)? What if the change is really small? Do you run a local web server for development? (I couldn't go through that process for simple CSS changes.. I'd go crazy!)
    – melat0nin
    Commented Mar 27, 2012 at 10:18
  • 1
    For a minor CSS change I would make the change directly on the server and then commit that change to the repository from the server. When I have to do a more serious amount of work on the site I would then update the site on my dev machine with the latest version of the site from the repository. I guess it doesn't really matter where you make the change (server or dev machine) as long as you commit it to the repository.
    – user43249
    Commented Mar 27, 2012 at 12:15
  • So what tools do you use for this? FTP to make the file changes directly on the server, then an SSH session open in the background to do the commits to the Git server now and again?
    – melat0nin
    Commented Mar 27, 2012 at 13:51
  • 1
    Yes, that's basically it. In fact I use Subversion. We have sites on Windows as well as Linux servers. On Windows I remote desktop onto them, make the CSS change and commit using TortoiseSVN. On Linux I use an SSH session and vim to make the changes (but you can also FTP your changes I guess).
    – user43249
    Commented Mar 27, 2012 at 14:37
  • I've gone with your suggestion of editing on the server then committing from there via SSH, which I've been doing for a few days now. Seems to work really well, thanks!
    – melat0nin
    Commented Apr 3, 2012 at 8:34
2

It's rather easy to create a post-update hook, that automatically updates (exporting with git archive is preferred for security reasons) the web server data directory when you push to a specific branch.

So have a git repository set up somewhere (for security reasons I'd put it on different server than the web) with such hook. You will of course need test server to test larger changes, which may be either on your local machine or updated by pushing to different branch. In either case you can bypass it for trivial spelling and CSS fixes by simply doing commit and push.

Improve this answer
0
1

I'd follow these steps:

  1. Set the remote server up with a proper public/private key pair for remote push/pull
  2. Set up two branches testing and release
  3. Develop locally with a test environment in the testing branch
  4. When you are happy merge with the release branch and push to the remote server
  5. Hook on the remote server to update to latest version of release

Set up one repo per website, to keep them from cluttering each other up. The separate branches allow you to avoid having the current "good" version lock stepped to what you are currently working on, which may or may not function.

Improve this answer
2
  • So am I understanding correctly - there are two servers (1) for Git, (2) live webserver, and one local development machine. Dev is done locally then pushed to the Git server which has a hook for updating the live server?
    – melat0nin
    Commented Mar 27, 2012 at 14:35
  • @melat0nin That's one way to do it. You can have the live server pull from the git server as a cron job too. Or, you can have 2 machines. The local dev machine, and the live production webserver. That way, pushing the repo from the dev machine to the production machine updates to the newest release branch whenever you push.
    – Spencer Rathbun
    Commented Mar 27, 2012 at 15:20

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.