Menu Menu

Learning to Work With .git

Benji Damron on March 25, 2014

I haven’t been in the Drupal world much lately. Other than basic core/contrib updates and the random config or module tweak, I’ve mostly been working in the world of .git - specifically trying to deploy with .git to our different environments.

.gitWe moved from perforce to .git late last year and it wasn’t without some wailing and gnashing of teeth. Our first hurdle was to get everything migrated over. Luckily, perforce tells you exactly how to do it in their knowledge base

If you are unfamiliar with or afraid of command line *nix, it may seem a little daunting at first but the directions are pretty straight forward. The only thing I don’t really agree with is telling people to rebase. You can read why that’s  a bad idea here. If you’re the only developer in your repo, it may not be a problem.

We have multiple devs in and out of repos all of the time. Everyone has gotten up to speed on using .git for commits, merges, branching etc. but we still have a little pain when it comes to deploying to our servers. We’re still working on our production sites but we have our stage servers pretty much figured out.

We found out pretty quickly why you don’t push to a repo with a work tree. And we wanted to find a way to keep us from doing hot fixes directly on the server (something you shouldn’t do but, it happens).

At first we were ssh-ing in and doing a .git pull. We use beanstalk as our main repo and the way they have things set up, it asks for a username and password every time - not a big deal but minorly annoying. Nine times out of ten there are uncommitted changes or a tip is ahead or behind so you end up doing a little work to make sure things sync up. Sometimes merges fail. And as most of you know, you can really mess things up ssh-ed into the server. Not the best solution.

So we looked into bare repos. This seemed like a great solution but we would have to set everything up ourselves and we would also have to set up our own security and permissions. Then we started looking into beanstalk’s deployment options for branches and users could be added/removed for each branch. Better check this out…

The first thing you’ll need to do, is navigate to your repo and set up an environment under Deployments:

Then select a server type or copy an existing server’s settings:

I usually copy an existing setup and make the appropriate changes:

I have .git editing the config file to add a user and email because you’ll get errors if you don't. I haven’t tested this but I imagine you could remove the 2 .git config lines after the first deployment. Beanstalk will then confirm that it can actually connect to the server (don’t forget to add your public key before an actual deployment). The next screen gives you options for adding pre/post deployment hooks (like clearing drupal cache maybe?):


And you're done!

The only other thing you need to do is give your devs the appropriate permissions:

And that’s it! Deploy away. No need to remember linux and .git commands.



START THE PROCESS  Schedule a Website Audit Schedule Now