3 ms·

git push/pull is easy, but there's no getting around the fact that Git is a distributed version control tool, not deployment software. Using Git for deployment

git push/pull is easy, but there's no getting around the fact that Git is a distributed version control tool, not deployment software. Using Git for deployment is probably fine for simple deployments where you're just getting a bunch of static files onto a single box, but as soon as you stray into the realm of non-trivial web application deployments then things change. Factors like database migration, dev/prod environment parity, dynamically spinning up new server instances and continuous integration etc. mean that the act of simply copying your files become the least of your worries. Sure Git will play an important part in getting a snapshot of the codebase from a dev's workstation into the deployment flow, but that's where it ends and tools like Chef and Puppet take over.

EnderMB 13y ago
My thoughts exactly. This workflow is nothing more than hacking Git using post-commit hooks to do something it was never built for. If you want to deploy using Git then the smart thing to do is to use one of the many continuous integration tools out there that were built specifically for this kind of workflow. I use TeamCity to run my tests and to build/deploy my website whenever I push to my default branch. This works really well for some of my sites, and although I'm looking for a way to refine this so I can also deploy database changes between local/staging/web servers I can't think of a better way of doing this.