Moving from FTP to Git deployment, a designer's guide
May 30th, 2013 | Adam Johnson
Moving away from FTP and onto Git is pretty straightforward. But what good is moving to Git if you're still using an FTP client to manually transfer files to your server (and thus, taking your files out of version control once more)? This post explains how to move away from FTP deployment, onto Git, and how to deploy straight from your Git repository—all for free. No fancy command-line jujutsu or server side tricks, lots of GUI's, very designer friendly.
Prefer a screencast? Yeah, I thought so:
If you already know Git and don’t need any introduction, skip to 9:56.
Why is Git deployment better than FTP deployment?
Saves time
Reduces human error (never forget a modified file)
Keeps your production site in perfect sync with your Git repo
Easily roll your Git repo back and redeploy if your live site breaks
Backs up your code in multiple places (no longer just on your laptop and server)
There’s a ton more reasons why using Git for version tracking & deployment is awesome, but you get the picture.
Prerequisites (aka What I’m not going to cover)
You need to know Git (or at least be interested enough to explore), your way around your server (things like connecting via (S)FTP, making directories, and the like), DNS, and all the standard stuff to get a website live on the web. Please note in the screencast I go over how to install and get going with Git, just as a super quick overview; however, I’m not getting super detailed with written instructions. Check the screencast out if you need more Git help.
BitBucket (although GitHub would totally work too…)
DeployButton (Update: now MIA!)
Lots of folks have talked about Git and BitBucket before, so I’m not gonna say much about them. Just know that I chose to use BitBucket for this tutorial just because they provide unlimited private repositories for free—something GitHub does not do.
Roll your own - Free foreva’, technical knowledge required, there may be dragons.
While most of these services do offer a free plan (usually a trial or for one project), it’s unlikely that you’ll be able to utilize their free plans due to their project limitations.
Update 8/21/13: Over the past few months, I’ve had some issues with Deploy Button. If you’re serious about deploying your project, I’d look into one of the services listed above. That said, your milage may vary.
Step by Step:
You gotta know Git to start using git. You have two routes here:
Option A: Learn git like a boss. Learning Git from the command line means you can use it anywhere, on any platform, with any service (not just with a GUI). It also allows you complete and total control/flexibility. The best resource here is try.github.com. I recommend going through their tutorial—a couple of times. After you’ve done that, do it for real. Install Git and do some git clone, git status, git add, git commit, and git push love to the Spoon-Knife repo.
Option B: Use a client to get your stuff up onto a Git based service. Likely the easiest route would be the Github client for Desktop. Native clients work okay until you need to do more advanced stuff. When you get there, check out SourceTree or the command line.
Sweet, you know Git. Now create the repo you’d like to deploy. Considering we’re still on the free train, you can put it on GitHub if you want it to be public, or you can use BitBucket to keep it all private and secret like. Create the repo, add some files, commit, and push. If you’re super lazy, you can fork someone else’s code and bring it under your masterful control. See the screencast if you need help and check out my instructions for sorting the notorious “Permission denied (publickey)” error.
Now, let’s deploy all the things! Setting up your details with DeployButton is stupid easy. Connect your account with BitBucket and GitHub—even DropBox if you fancy that route. After that, you give it the same credentials you give your (S)FTP client. Shoot, you can copy and paste if you like. During this process, be sure to make a folder with your favorite (S)FTP client that you’ll deploy to. Then hit that giant red “DEPLOY” button. Watch the magic happen (DeployButton will connect to your server and BitBucket, get all the codez, and deploy). After all is said and done, double check via (S)FTP that your files made it up to the server.
Congrats! You just moved your stuff to Git and deployed it to your server. Not too hard, right?
You should note that, while DeployButton does use Git, Git itself doesn’t have to be installed on your server—which is super handy for those readers on shared hosts. It means Git stays with your local machine along with GitHub/BitBucket/etc. Your production server has no specific Git-based requirements in order to make this happen. Nifty.
Some error bringing your world down?
Learning Git is gonna be a bumpy road. Keep yer’ head up, kid. After that, Google it. Someone has definitely run into the same problem you’re seeing—and figured out how to fix it. There is always hope. As I mentioned before, a super common error is Git not being able to push to GitHub/BitBucket/etc due to a Permission denied (publickey) error. Here’s instructions on how to create a publickey and add it to GitHub/BitBucket.
Should I track the core of my CMS?
This is somewhat personal preference; however, be aware that the “core files” for whatever CMS you’re using (Concrete5, Wordpress, Drupal, et cetera) likely have a metric shit-ton of files in them. That means, if you choose to track the core of your CMS, everything you do will take longer (think git status, git add, git push, et all). Thereby, to start, it’s probably a good idea to look into making a .gitignore file and ignoring the core of your CMS for your Git repo.
Earlier, I mentioned how this is not the only option. While this may be the easiest (?), DeployButton could one day spontaneously combust, leaving you in the lurch. I plan to write a blog post about Ryan Florence did a wonderful job explaining how you can roll your own system for Git deployments. For now, grab a beer, celebrate moving to Git, and pat yourself on the back for being more awesome.
If you have other resources on deployment, write a blog post and let me know. I’ll link to them here. Extra points if they are wicked simple and well documented.
I’ve recently removed comments from this blog. Want to chime in? See something wrong? Email me at Email me!. I’d love to hear from you. I read every email and welcome your input.
