Finally, we'll set up a post-receive hook for git to check out the master branch so your web server can serve files from that branch. (Remember, ^D is Control+D, or whatever your shell's EOT character is.
(a) I Haven't looked into multi-server deployment, sorry.
(b) Just use git push origin master -f to force when it's not a fast-forward.
(c) If there's a build, script it and add it to the post-receive hook. It's just a shell script.
(d) That's true, but this assumes all your files are in the git repo. If not, you'll have to update those manually (such as via scp), or add something in the post-receive hook to take care of it.
Using an SCM (be it GIT, svn, hg or whatever) is an excellent means of distributing all kinds of assets - images, control files, scripts. I even know people who keep their .bashrc and .profile files (and other portable tools) in github and pull them down as they move to different client sites. The efficiency that comes with versioning, hosting and accessing through these tools can make you look super-organised
I came up with deliver https://github.com/gerhard/deliver to address this very problem. It's bash utility that automates git-based deploys and comes with pre-built strategies for the most common deployment scenarios: generated sites (think Jekyll), shared (WordPress, PHP etc.), ruby, node-js, S3 etc. I did a talk on it at my London Ruby User Group in March: https://speakerdeck.com/gerhardlazu/deliver
It's pretty cool, although pull deploys scale better. Simples implementation of pull deploy would be with cron job fetching the git repo and more advanced way is to use Chef or Puppet for it, so that you can also introduce configuration changes in line with code changes.
Oh, how cool is that? Not really. Used it years ago with subversion and other SCM. You can also use Dropbox and other methods. Your tip is so 2000.
But coming back to git or better SCM: never ever use the Master branch. I say never. That is so wrong. Use a dedicated branch or a tag or similar, especially in a multiuser environment. You need someone who has the knowledge who will guarantee, that the final deploy will work. You cannot guarantee that in the master, when several users have write access. You need someone who gives the final go after review.
The biggest problem with git is the scalability. We currently use it in an awsautoscaled environment. When the servers come up, obviously nothing is on /mnt. This causes git pack to cause high com and high io in the master as it computes from commit 0. This can be solved using shallow copy, however, there are major bugs with that if you use branches and you risk deploying the wrong code to the wrong server.
So what is the solution? We are still working on a good one. Right now wend up mounting an nfs mount when the server bootstraps and copy over a base image of the repository avoiding git pack-objects and the delta overhead which goes with it. Is it the answer? No. The hunt for that continues.
Just doing a git pull --rebase in another directory (that isn't your webroot), copy to webroot, then remove the .git/ directory (plus any other sanitizing you'd like) is both low-risk and easy to script via something like Fabric or Capistrano.
Why wouldn't you just use a tool like Capistrano? Capistrano can deploy from Git as well, but it follows best practices like exporting a bare copy of the repo. It also provides niceties like rollback and ordered tasks (with before/after hooks) for that moment when you realize that you need to do something outside of dumping code in to a directory. Tacking on ad hoc bash scripts is what you do when better tools aren't available.
I'm all for exploring new ways to do the same old things, but this just strikes me as terribly incomplete and introduces some bad practices, like hosting a full copy of your git repo in the httpd document root.
To be honest, this feels totally wrong. Writing 15 lines of command-line code, some of them totally cryptic, for a simple deployment, does not feel "simple", clean and professional. I would recommend professional Continious Integration tools and doing deployments with one click/command AND having the possibility to roll-back anytime.
I think it makes more sense to deploy onto a stage, and archive the deployment files, then push them to the server in some way that is simple.That way they are assured to have been created.
We have been using VCS to do deployments of Wow addons for years, that has worked great - but you still have to wait for the built product to be prepared so you can post it ti alternate sites. It is nice though to have your build updated every time you commit.
Trying to get this to work and I've gone through the entire process but I still get a "'/html/newproject' does not appear to be a git repository" when I try to push. I'm ssh into godaddy shared hosting. I try to do ssh://username@hostname/html/newproject but apparently that's not right. All the git files show up if I ftp into it.