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.
Best Answer
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).