git

GitHub is a great central repository silo for open source projects, and for private Git repositories for companies and organizations with enough cash to afford the features GitHub offers.

However, for many projects and developers, GitHub can be overkill. For my needs, I have many smaller private projects that I'd like to have hosted centrally, and backed up, but don't warrant BitBucket or GitHub accounts. Therefore, I've taken to creating bare repositories on one of my Linode servers, and pushing all my local branches and tags to these repos. That server is backed up nightly, so I know if I lose my local environment, as well as my Time Machine backup (a very unlikely occurrence, but still possible), I will have backed up and fully intact Git repos for all my projects.

I recommend you do something like the following (presuming you already have a Git repo on your local computer that you've been working with):

After reading A successful Git branching model [nvie.com], which I consider one of the best graphical/textual depictions of the ideal Git model for development teams (and most large projects), I simply wanted to adapt a similar (but way less complex) model for some of my smaller sites and multisite Drupal installs.

Since I'm (almost always) the only developer, and I develop locally, I don't want the complexity of working on many branches at once (master, hotfixes, develop, release, staging, etc...), but I do want to have a clean separation between what I'm working on and the actual live master branch that I deploy to the server.

So, I've adopted a simple 'feature branch model' for my smaller projects:

• master - the live/production code. Only touch when merging in a feature or simply fixing little bugs or really pressing problems.
• [issue-number]-feature-branches - Where I work on stuff.

Graphically:

Borrowing from answers in this Stack Overflow question, here's how you can get through a corporate (Microsoft) NTLM Proxy to clone git repositories from drupal.org:

cd into your drupal contrib directory (or wherever you want to put the repository).

$ export http_proxy="http://username:password@proxy:port/"

$ git clone http://git.drupal.org/project/[projectname]

Basically, you're first setting an environment variable to tell your shell to use an HTTP proxy, with your username/password combo. This variable will be used when making connections to git.drupal.org (and other services, like github). You can also set this in your ~/.profile, .bash_rc, or .bash_profile so it will be saved for future Terminal sessions.

This is half for my own reference, because I have a few other computers I still need to set up, and I don't want to keep referring back to drupal.org docs to get everything ready for Git.

In case you've been under a rock lately, drupal.org was down for a while yesterday, while a team of dedicated Drupal peeps spent a few hours migrating everything in drupal.org's version control system (which was running CVS) to Git. Git is an excellent tool for version control, and I've been using it for a few months for my personal projects (most recently, I've started using Tower on my Mac to make Git easier).

Without further ado, here are the steps/links you need to 'git' started with Git on drupal.org:

A few weeks ago, I heard rumors of a new Git client for the Mac that was supposed to be even easier/prettier than my past favorite, GitX (specifically, brotherbard's fork of GitX). GitX is simple, and very usable, but just feels rough sometimes. But... it's free, so it is very nice in that way.

Yes, I often work on the server. "Do what I say, not what I do."

This new Git client is Tower, and it is awesome. I paid for two licenses for my two Macs, and I highly recommend it for other Mac users deeply invested in Git. The interface is simple, it has searchable commit logs, it lets you stage and unstage (and modify) changes and commits with efficiency and ease, and it is $50 well-spent. Check out the Tower demonstration video on YouTube.