Git: A Designer’s Perspective

Let me start by saying I'm not one of those super tech-minded designers who loves to dive into new programs. Especially when those programs involve heavy use of the command line and every tutorial written about them is so technical it might as well be in another language. I was happily tooling along using Tortoise SVN through VMWare, slooooowwwwwly moving through my SVN checkouts without much complaint. And then two of our developers, David and Ben, pulled me aside one day and told me that instead of using SVN, I'd be using Git for our next big project. I remember sitting in Ben's office thinking, "Crap... what kind of learning curve does this thing come with?" I barely knew what I was doing with version control in SVN, and here I was faced with the prospect of a new (and arguably less n00b-friendly) program and process.

A few weeks later, the project really got rolling, and David was tasked with setting up my machine with all the necessary stuff to allow Git to run on my Mac. This was a fairly involved process, partially because my Mac was a little out of date. He had to install MacPorts, Git, MySQL, GitX (a handy little GUI), and update my Ruby gems. Then he had to show me how everything worked and wait patiently as I scribbled every single step and command down in my trusty notebook. I watched and absorbed as much as I could, but it all looked pretty foreign to me.

So what is Git, exactly?

Once installed, my learning began – and I had a lot of ground to cover. I started reading up to make sure I had a grasp on what I was doing when I typed commands into Terminal. Here's what I learned:

Git is open-source distributed revision control software Linus Torvalds originally developed to manage Linux kernel development. The key word here is "distributed." This is one of the things that differentiates Git from other revision control solutions such as SVN. Git runs locally and does not require a network connection. Everyone involved in a project will have their own fully functional Git repository on their machine. This makes most processes super fast, and it also provides built-in backups for your repository. Since each person has a copy of it locally, you never have to worry about a central server crashing and taking all your work with it.

Git highlights include

• Better branch handling. To be honest, I haven't used branching yet. But from what I hear it's much easier to do in Git, and developers love it. I can see myself using branching in the future for implementing big and possibly experimental changes. Branches will let you test out new things (like a new layout, for instance) without breaking what's already there.
• Speed. Since all your operations are performed locally, things like committing changes run extremely fast.
• Smaller space requirements than SVN. The files you store are significantly smaller.
• The distributed model means you can work on a project without a network connection (say, on your laptop on a park bench enjoying the sunshine) and synchronize it later.

What am I using it for?

Here at Viget, designers are responsible for front-end development. I'm currently using Git to share files with three developers (David, Brian, and Ben) for a Rails application we're building. At first, I just checked in my markup templates and the developers merged them with their working code. After a while I started working directly on the Rails files. It was comforting to know that I couldn't really ruin anything since there was always way to restore it if I happened to make a mistake.

How do I use it?

I work on a Mac, so this will be Mac specific. To get started, I open up Terminal and start my local MySQL database, since the application we're building requires one. Once that is up and running, I check out all the latest files from our master repository. I do this with one quick command – git pull. This grabs everything new and updates my local repository.

Once I have the most recent files, I fire up my editor of choice, TextMate, and start my work for the day. As I complete major tasks or milestones, I make commits. Commits are sets of changes which I document with a quick message and then push up to the master repository. To commit changes I use a simple GUI for OSX called GitX. The GUI is not necessary. You can easily commit changes using the command line or use this TextMate bundle to commit from within your TextMate project window. But I am a very visual person and find the process much easier to understand when I can see what I'm doing.

In GitX's commit view, you will see a list of uncommitted changes in the lower left. Drag them over to the "Staged Changes" area on the right, add a message, and hit the Commit button. Note that you can do this with multiple files – you don't have to add each one separately.

I commit pretty frequently to keep myself on track. I have a terrible short term memory, so if I don't commit frequently, I end up with a list of files a mile long and no clue why I touched them. Luckily, GitX has a diff view. All I have to do is click on a file to see what has changed. In the above screenshot you'll see the old code marked in red and the new code marked in green.

After I've committed my files, I flip over to GitX's History view. In this panel I can see all of our recent commits, complete with the message, author, and date. If my local repository is not in sync with the master repository, the indicators at the top (in green and light blue) will show me where my files are in comparison to the master files.

If my repository is behind, I perform another "git pull" to merge the latest changes. Then I perform a "git push" to move my local changes to the master repository so that other team members can check them out. I push at least once a day, but usually more often than that.

Bonus tip: Occasionally, there comes a time when I need to pull but don't want to commit my changed files first. Usually because I screwed something up and don't want the developers to see what a mess I made of their code.  When this happens, I do a "git stash." This stashes my changes away somewhere while I pull the new files. After the pull I just type in "git stash apply" and voilà – my changes are applied to the newest files.

Want to get started?

Download the latest version of Git at http://git-scm.com/download, then check out these links for help and insight:

From Viget blogs:

Getting To Know Git
A Gaggle Of Git Tips
Effectively Using Git With Subversion

Elsewhere on the web:

The Git User Manual
Version Control For Designers
Understanding Git Conceptually
Why Git Is Better Than X
Git Magic: Basic Tricks
Git Crash Course
Git Cheat Sheet

Props

I have to thank the Viget South developers, and especially David, for being incredibly patient with me as I muddled through the first few weeks using Git. Because they take the time to show me how and why when things go wrong, I have learned a ton and can usually resolve issues (like a merge conflict) on my own. All designers should be so lucky. Then we might not be so afraid of the command line!