As 2014 winds down, we’ll take an opportunity to look back at some of our most-read posts from this year, in case you missed them the first time.
Photo by Richard Atkinson, http://www.flickr.com/photos/richardatuct/6719197685/
Noah Miller gives us a useful list of git commands that are handy to have at your fingertips….if you can remember them:
I’m thankful for git for many reasons, like fast commits, offline history browsing, and cheap branching. But one complaint I have is the illogical naming and arguments of git commands.
I’ve long kept a list of useful but hard to remember commands in a notepad. Here’s my list, roughly sorted by most frequently used. Careful with the dangerous commands at the bottom.
Deploying your webapp is an important part of the web development equation – your client’s site isn’t going to attract a lot of attention sitting in your local dev directory. Deployment concerns tend to fall to the bottom of the priority list, though, and the end result tends to be kludgy, hastily thrown-together deployment scripts; and because they are so kludgy and, often, time consuming, when time crunches threaten, a developer may resort to making changes directly on the remote server that need to be (but sometimes never are) backported to the code living in your version control.
Wouldn’t it be better if you could deploy your newest code with a single command, using the same tool you use for version control? One
git push, and your site is serving your newest commits. No more kludgy, multi-part scripts, no more threat of overwriting critical fixes with the next deploy.
Let’s make that happen.
Your code isn’t getting any better sitting around undeployed, let’s get it out there.
Continuous Integration is a good thing. Get your commits tested and deployed fast and hassle free and the rewards will pile up in your lap. So what’s the least amount of work it would take to get a simple continuous integration pipeline set up? We want to know when a commit has happened; run the tests; and deploy to a staging server. Let’s say we have a python project, using git for version control, deploying to heroku. Deploying to heroku and running nosetests are both super simple so will this be easy?
A year ago, I was happily using Subversion for my version control, and reading about Git. It sounded intriguing, and there were lots of articles about the life-changing enlightenment of switching to Git. Frictionless branching and merging? A whole new elegant model of file management? Plus I get to think about directed acyclic graphs? Cool.
For the last few months, I’ve been using Git pretty much every day. But sadly, I’m still waiting for the epiphany. Here’s how I reckon up the pros and cons. Maybe it will help someone else with this transition. (Please note that I don’t have the pleasure of knowing other nifty new distributed version control systems like Bazaar and Mercurial.)
Let’s start with the good stuff. (more…)