Can/Should I put my Git repository on a non-dev machine and keep it synced with the non-version control server?

Question

I volunteer for a website, and well, basically, we don't have version control. We're working to change that, but because of several things, including the fact that I haven't worked with source control before, that's not happening for some time.

In the meantime, I'd like to move my working files into source control (probably Git) for the obvious benefits. Here's the thing: there are hundreds of thousands of files on the web server that are user-generated that I don't really want on my dev machine because, well, I pay for my own equipment (it is volunteer after all, so it's not like I can expense a new hard drive) and my dev machine is also my everyday computer and I'd rather not clog it up with a lot of stuff that doesn't need to be here.

I do, however, have an empty system sitting around that is perfectly willing to store all of that data. In all likelihood, that system is probably going to host an entire local copy of the site anyway as a backup. So, and I hope this isn't an entirely crazy idea, I'm thinking about putting the Git repository on that machine. I'm not intending to develop on that machine, however.

So,

• Is putting your Git repository on a different computer than your dev machine a really bad idea? It should be technically feasible as it's on the same network, and I don't think my IDE will have any problem connecting to it, but that doesn't mean it's a terrible idea. Putting the repository on my dev machine isn't out of the question, but it'd be preferable to put it on the empty one.

• (And I hope that this is related enough to keep in the same question) Because there are other people working on the site, changes are going to happen to the remote site that aren't going to go through source control. Since I'd prefer the two to stay synced, could I create a Git repository on the server, pull and merge changes into my local, and then just upload the changes through FTP? Doing any real version control on the server isn't feasible at the moment (as I said, it's being worked on), but a repository that we don't touch is a different matter. Would this be a feasible plan at all?

Answer 1

Yes, it is possible as you described it, but very, very inconvenient and error-prone. If your repo is on another machine, you would have to copy the current state (HEAD) to your dev machine to work on the files, then copy them back to even commit something. That completely destroys one of the best features of DVCS's: cheap and fast local commits. Also, you don't only use version control as a dumb backup storage: it has history, bisect, branches, merging etc. You want that on your fingertips, without a round-trip to the other machine. Another possibility, if you are using *nix based OS on both machines is if you set up an SSH connection and work through that. That's not terribly hard, but still not optimal.

Now, I think that your repo (minus the user-generated contents) is not going to be terribly huge even with all history (I might be wrong, but unless you store and modify lots of binary data in the repo, git tends to be fairly compact). Usually, people don't store content in the repo, only code (well maybe some minor test data). So what you should do is write a suitable .gitignore file that filters out the things you don't want. The user-generated content, especially if the items are not only added but changed over time, is not something you want to version. You can still put a clone of the repo on that other machine and even on the production server. That way, deploying your changes would be a git push.