Let's deploy via Git

This is a pretty neat hack, but not really good for a true production deployment system. Rsync is a far superior alternative. That being said, git should definitely be incorporated into the workflow such that, for example, you have a &quot;live&quot; branch which always reflects what is to be on production frontend nodes. From there you do 1) git pull origin live 2) rsync to live servers 3) build&#x2F;configure&#x2F;restart&#x2F;etc. Set -e on that script obviously...<p>Edit: I should also mention, if you are stuck on something like restricted hosting with CPanel which severely limits your deployment options (some of my clients are in this boat), then <a href="http://ftploy.com/" rel="nofollow">http:&#x2F;&#x2F;ftploy.com&#x2F;</a> is a really cool solution. But you should really get your ass off cpanel asap.<p>Double edit: Some of the replies below have made some good points that I had not considered which weaken my argument. So while I&#x27;m now more ambivalent than dismissive towards the idea of using git to deploy, there are several modifications that should be made to this particular system to make it production-ready. See avar&#x27;s and mark_l_watson&#x27;s comments below and mikegirouard&#x27;s comment elsewhere for some ideas.

I&#x27;m a huge Git fan and use it every day, but Git was never designed as a deployment tool. There may be situations where you want the entire history of your development to be included on your live server, but often this just isn&#x27;t appropriate. Also, when deploying to multiple servers you have to invent adhoc methods to handle configuration differences. Even native ssh seems like a more prudent deployment method than Git. This smacks of using the closest hammer at hand, rather than choosing the best tool.

Aaargh !<p>Build on a build server<p>Scp to live server along with generated config<p>Install with native package tool and hook into native service manager<p>Use salt &#x2F; puppet &#x2F; chef to do everything after initial build on your target servers.<p>Be nice.

I use git to deploy about 30 sites and have found it to be a really useful workflow. It&#x27;s particularly useful over SSH when using key-based authentication.<p>For my post-receive hook, I always add a tag to mark a deployment:<p><pre><code> git tag deployment-`date +&#x27;%Y%m%d%H%M%S&#x27;` </code></pre> You can see all past deployments with a git log:<p><pre><code> git log prod&#x2F;master --oneline --decorate </code></pre> On all my developer machines, I have them add a `git-deploy` script to their $PATH, which looks a little something like:<p><pre><code> #!&#x2F;bin&#x2F;bash git push $1 +HEAD:master git fetch $1 </code></pre> You can just run `git deploy prod` (assuming your deployment repository is named &#x27;prod&#x27;).<p>The extra `git fetch` will pull down the auto-generated tags so you can see them locally w&#x2F;a simple `git tag`<p>Edit: Forgot to mention, that since git ships w&#x2F;a bash shell for Windows, most of this should work for Windows-based dev setups as well.

Pedantic nitpick -<p><pre><code> git remote add origin git push origin master </code></pre> It shouldn&#x27;t be called &quot;origin&quot;, because it isn&#x27;t really an <i>origin</i>. A more fitting name would be &quot;live&quot;.

git is a SCM and should not be on production systems.<p>instead you should have a build server which builds up a package (rpm, deb, tarball?) which is then used to deploy across the production environments.<p>you should also not compile JS&#x2F;CSS etc on production system that is what the build server is for.<p>anything installed on a production system should be &#x27;required&#x27; for the app to actually run.<p>-<p>that said, you can use capistrano (and other tools like this) to update &#x27;demo&#x27; environments and dev environments (with git) however the actual TEST and STAGING environments should mirror the PROD environment (packaging).

I&#x27;m planning on writing about this in more depth later, but this is essentially the route every cloud hosting company is taking right now and I think it&#x27;s a bad to only allow that kind of deployment.<p>Don&#x27;t get me wrong, I love Capistrano, git deploy hooks, ruby gems that do deploys (heroku), but most cloud hosts are only offering this mechanism to deploy apps. FTP became popular because of the ease of use for designers and webmasters. You don&#x27;t always need to deploy your entire application for simple changes. Another big one is the ajax file editor in the browser.<p>For trivial changes a simple file change would suffice. When you do an entire deploy for app like this, depending on your dependencies and payload, it could take a long time. What if you had the wrong price and need to make a change immediately? Of course maybe now there are multiple environments which play a factor too.<p>I do realize that was before we had multiple web servers running the app and that is part of the reason, but there are still ways to make it work (file mounts).<p>I&#x27;m hoping more deployment options in the future and that cloud hosts realize the need is still there from traditional hosting.

I&#x27;m trying git to get my feet wet with it but man this looks way complicated to me. I didn&#x27;t even know about &quot;git config&quot; or even that there was a checkout command for git. I usually cd into the directory I want to turn into a repo and use &quot;git init&quot; then after changing files, run gitk or if in Eclipse I use EGit. I&#x27;m not even sure what happens in gitk when I do a commit, is it that long &quot;push master origin&quot; stuff? Does that mean master is my local repo and master origin is like the overall master? I guess with SVN it&#x27;s clear even at the command line but with git there are just so _many_ options. Then there&#x27;s custom scripts to make all this work? I&#x27;ll stick with scp or rsync for distribution for now. The author might want to look into Hudson or Jenkins, they work wonders.

git push&#x2F;pull is easy, but there&#x27;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&#x27;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&#x2F;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&#x27;s workstation into the deployment flow, but that&#x27;s where it ends and tools like Chef and Puppet take over.

Don&#x27;t forget to hide your .git directory. You could accidentally expose all your source code to the web.

The issue here is that there is still numerous web hosts who don&#x27;t grant you SSH access, so you&#x27;re not able to set up any git repository there anyway and are still stuck with FTP. Hopefully this will go away soon, or at least more in the direction of Heroku and the likes.

I came up with deliver <a href="https://github.com/gerhard/deliver" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;gerhard&#x2F;deliver</a> to address this very problem. It&#x27;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: <a href="https://speakerdeck.com/gerhardlazu/deliver" rel="nofollow">https:&#x2F;&#x2F;speakerdeck.com&#x2F;gerhardlazu&#x2F;deliver</a>

I&#x27;m not sure I like the approach of serving files from your repository. I&#x27;m not sure about how git works in detail, but are repository updates even atomic?<p>When I deploy my website, I use a different approach: My webroot is just a symlink. My deployment script exports the repository to a directory with a unique name for every commit. When the export succeeds, the symlink is updated to point to the new directory.<p>The advantage: Changing to the new version is instantaneous. If something should go wrong, I can immediately revert by changing the symlink back to the old dir.

Here&#x27;s one reason not to use git for deploy - if you don&#x27;t want your source code on production servers where clients can access it, or where it could be found by hackers.<p>I work on a closed source system, so we will never deploy our code via git and then build on the server. So, in this case build locally (or on a build server), and rsync from there using deploy scripts.

I&#x27;m surprised Fabric [<a href="http://fabfile.org" rel="nofollow">http:&#x2F;&#x2F;fabfile.org</a>] has not been mentioned in this thread. I&#x27;m not a Python developer but I love Fabric specifically for a tool to handle deploying code. If you feel like a Git deployment is lacking, be sure to check out Fabric, especially for multi-server deploys.

FTP still works. FTP isn&#x27;t &#x27;broken.&#x27; This &#x27;replacement&#x27; adds huge unnecessary complexity and doesn&#x27;t work on nearly as many servers as FTP does (which is <i>all of the servers</i>)<p>And yes, I have deployed with git, so i&#x27;m not speaking out of complete backwards ignorance. I can still see a use for both.

Yeah, Python and other technologies are also 90&#x27;s or even older - what is your point? Proven technologies that work are belittled to promote today&#x27;s agenda?<p>I would tend to dismiss this kind of articles and suggestions even if they are OK - only because they promote by appeal to a fashion.

I had written a very similar article a while back which includes some django specific points and is also intended to be really simple to read thru:<p><a href="http://thomaswilley.com/?p=9" rel="nofollow">http:&#x2F;&#x2F;thomaswilley.com&#x2F;?p=9</a>

And add some directives to your http server to not serve your .git directory, too!

A beautiful thing that this demonstrates is that no matter how old a concept is, there&#x27;s always room to explain it clearly so that those who didn&#x27;t already understand it have the benefit of finally being enlightened. I learned this many years ago as an author, thinking that my most basic ideas weren&#x27;t worth writing down. It turns out that what&#x27;s obvious to one person isn&#x27;t obvious to everyone else.<p>Thanks for the reminder and for the clear explanation of how git deploy might work!

In the Drupal community, we&#x27;re all stumbling over each other to find the best Git deployment strategy. I&#x27;m surprised that Git deployment would still be news for anyone. I don&#x27;t know who this article can reach that&#x27;s not already competent enough to be using Git (at least for dev).<p>On the other hand, if your site is just static (HTML&#x2F;JS) files, I think it makes great sense to use Git to deploy, as there is no configuration to worry about.

Was looking for an email address for the author! And failed. Anyway just wanted to comment - that there&#x27;s no publish date attached to the article - or one that is at least obvious. I have no idea when it was authored.

&gt; (Remember, ^D is Control+D, or whatever your shell&#x27;s EOT character is.)<p>Use a heredoc <a href="http://tldp.org/LDP/abs/html/here-docs.html" rel="nofollow">http:&#x2F;&#x2F;tldp.org&#x2F;LDP&#x2F;abs&#x2F;html&#x2F;here-docs.html</a>

And here I was thinking that this was obvious and most people used something like Capistrano... It&#x27;s shocking to me the amount of people not using some sort of SCM-based deployment method. =P

I personally prefer git-ftp. It is common that ssh is still only luxury.

I&#x27;m from the 80s. I bet you want to replace me also.

Shouldn&#x27;t it be:<p><pre><code> git --bare init </code></pre> On the server?

Balls of steel deployment

git push. <i>no no</i> rather tag and checkout&#x2F;sync etc

make a tag, push the tag, at least.. at the very least :P

Terrible idea..

Or use Heroku.