Best practices for a single developer webproject setup
I am quite new to GIT, so please forgive me any stupid questions (if there is such a thing 🙂
- One local repo on my dev machine (Win 7, Eclipse)
- One dedicated server hosting a testing site and a production site (Win 2008 Server, Admin permissions)
- Being able to work on my dev machine and push all changes (after local commit) to the testing site
- Once tested on the dedicated server, I wish to publish the changes from my dev machine to the production site
- I need to secure the repos, can anyone point me to a tutorial on how to achieve that on windows machines
- Does the .git folder need to reside in the public http directory or is that a bad practice with respect to security?
- I figured to work with a SSH setup since HTTP is slow and insecure. What other recommendable options do I have?
- Would I be best advised to use patches or rather merge the stable/tested branch to my dedicated server?
Any help is much appreciated!
- How to setup multiple identities of git ssh on windows?
- GitKraken config file
- Egit very slow at handling big projects
- Work with git on Windows 7 machine
- Which user executes the post-receive hook on a Windows machine?
- git: determine if there are file that are not on repo, but should be added
2 Solutions collect form web for “Best practices for a single developer webproject setup”
I need to secure the repos; can anyone point me to a tutorial on how to achieve that on windows machines?
What exactly do you mean by “secure the repos”? Just dealing with the server being exposed to the internet? SSH should be plenty for you in that case. If it’s just you, I probably wouldn’t bother with anything fancy like gitolite – just create a bare repository on the server, and don’t make it available any way but via SSH. I’m not sure what setup advice you need either – you just need to be able to ssh into the machine, and access the path to the repository.
Does the .git folder need to reside in the public http directory or is that a bad practice with respect to security?
It’s up to you whether you want your production site to actually be a repository. It does make it easier to fiddle with, but you’ll want to configure your web server not to give access to the .git directory. If you’re paranoid, it’s also quite possible to deploy without it being a repository, though, for example using git archive. The idea is simply to dump a copy of the current version into the given directory.
I figured to work with a SSH setup as HTTP is slow and insecure. What other recommendable options do I have?
SSH and HTTPS are the two git transfer protocols to consider if you want security; there’s not really any reason to look beyond them. SSH should be much easier to set up and work with. (Git does support several other protocols, but they’re all either not intended for secure use or simply not as widely used.)
Would I be best advised to use patches or rather merge the stable/tested branch to my dedicated server?
I assume you’re asking about the production site here, since you mention the tested branch. This of course depends on whether or not you have a repository for the production site, or if it’s just a checked-out copy of all the content. In the former case, there’s absolutely no reason to use patches. Just pull into the production repository:
cd /path/to/production-site git pull /path/to/testing-site stable-branch
If your production site isn’t a repository, I’d probably do something like this:
# check out a copy of the updated version git archive --format=tar --prefix=new-site HEAD | (cd /var/www && tar xf -) # swap it into place mv /var/www/site /var/www/old-site mv /var/www/new-site /var/www/site rm -rf /var/www/old-site
I’m a Linux guy, obviously, so those instructions might require a little modification for Windows, but the idea should be pretty clear.
It’s better that the public HTTP directory not be a git repository, just in case – your full git history should be private. You can keep a repository somewhere on your hard drive that isn’t served by the HTTP server and use
git checkout-index or
git archive to create a content-only snapshot (see this question).
SSH is great for your purposes, secure and offers good performance.
Don’t use patches – sync the trees with push/pull over SSH, then take the relevant branch for your production and testing sites. The protocols are efficient, and shouldn’t take long to sync. You can even sync continuously, not just when you want to deploy.
You can try these instructions from Lifehacker for setting up a an ssh server with openssh on cygwin.
Setting up git clients on Windows is simpler, so you may consider having an external git repository (either on a *nix machine which is trivial to set up, or using a hosted git repository) and pushing there from your dev machine, then pulling from your testing and production machines.