Jake Scruggs

Recently we deployed to production without a key bugfix and my assumptions about git were to blame.

We, like other people who use git, do a lot of our bug fixing in a branch and then merge it into master when it's time to release. So here's the procedure for the guy who's turn it is to do a deploy (which was me):

1. Do a 'git pull origin master' in the master branch
2. Get a local tracking branch of the bug-fixes branch
3. Merge the bug fix branch into master
4. Tag the master branch with the name of the release (our deployment keys on tags)
5. Start the automated deploy script

Easy right? Except that my years with subversion have put in my brain this assumption that my source control will talk to the remote server all the time. But git's model is to use all your local info unless you specifically tell it to go over the wire. So when I told git to create a local tracking branch it did using the latest information it had locally about that branch. The last time I had done a general 'git pull' was a day ago so I got a version of the bug fix branch that was missing a commit that had happened the day of the deployment. And of course when I merged into master I was missing a crucial commit.

One of the cool things about git is the fact that you can do a lot of development without an internet connect, but I've found that a fair amount of the gotchas I've run into with git trace back to my expectation that it will talk to the remote server when it's preference is to stay local.