Intro to Git for Web Designers

Unless you’re a one person web shop with no team to collaborate with, you’ve experienced the frustration that goes along with file sharing. No matter how hard you try, when multiple people are working on a single project without a version control system in place things get chaotic.

If you work with developers on the buildout and implementation of websites, the merge between front-end templates and back-end functionality can be a scary black hole.

Issues like overwrites, lost files, and the all-too-common “working off a previous version” phenomenon crop up constantly. And once back-end functionality has been put into your templates, you become terrified to touch them for fear of breaking something a developer spent a great deal of time getting to work.

In addition, even if you have a common repository that everyone is pulling from odds are at least one member of your team forgot to grab the latest files and is about to blow things up with their latest additions.

In this article, I’ll give you a quick review of Git, an excellent version control system.

Version Control – A Quick and Dirty Explanation

Version Control (also known as Revision Control or Source Control Management) is a great way to solve the file sharing problem.

The basic concept is this: there is one main repository for all of the project files. Team members check files out, make changes, and then check them back in (or commit them). The Version Control System (VCS) automatically notes who changed the files, when they were changed, and what about them was new or different.

It also asks you to write a little note about the change so everyone on the project knows at a glance what you did and why. Each file will then have a revision history so you can easily go back to a previous version of any file if something goes horribly wrong.

A good VCS also allows you to merge changes to the same file. If you and another person work locally on the same file at the same time, when you push these files back into the main repository the system will merge both sets of changes to create a new and fully up-to-date file. If any conflicts arise during the merge it will highlight them for you.

You’re probably using a very crude VCS right now to keep your files straight. If you’re a designer, it looks something like this:

This works well enough for PSDs and other large binary files, which don’t really lend themselves to VCS. But there’s a much better way to do it when you are managing the source code for a website.

Benefits to using a Version Control System include:

• Files cannot be overwritten
• There is a common repository that holds all the latest files
• People can work on the same files simultaneously without conflict
• Allows you to revert back to an older version of the file/project if needed
• Making your developers very happy

Even if you don’t work with a team, version control can be a lifesaver. Backing up files is one of the easiest things you can do to save yourself from losing work or having to start over.

The idea of a VCS seems daunting at first, especially since most of the documentation is written by and for developers. But once you make the move to incorporate it into your workflow, you’ll find it’s not nearly as hard as it looks.

Meet Git

OK, so now you can see why a Version Control System is a must-have for your web team. If you do a little Googling you’ll see that there are quite a few options out there including SVN, Mercurial, CVS, Bazaar and Git. Any one of them could be a good solution for your needs, and I encourage you to do some research before selecting a VCS. In this article I’m going to focus on Git, the one I use daily. It’s a “rising star” that has gained popularity thanks to a strong Linux fanbase, GitHub and the Rails community.

Git is a free open-source Version Control System originally created by Linus Torvalds for Linux kernal development. Linus is a very smart guy; when he sets out to solve a problem, he doesn’t mess around. One of Git’s big differentiators is that unlike SVN and CVS it is a distributed version control system. This means that every user has a complete copy of the repository data stored locally on their machine. What’s so great about that? A few things:

• Everything is local, so you can work offline
• There is no single point of failure. It doesn’t rely on one central server that could crash and burn, taking the only repository for your project with it.
• Because it doesn’t have to communicate with a central server constantly, processes run much faster

Git has a slightly tougher learning curve than SVN, but the tradeoff is worth it. Just think how impressed your developer friends will be when you tell them you’re using the new hotness that is Git! In all seriousness, I don’t think the learning curve is all that steep. SVN was equally confusing for me at the start, and I ran into more day-to-day problems when using it.

Installing Git isn’t fun and games. I was lucky to have a knowledgeable developer willing to help, but there are plenty of resources online to get you through it. It will run on a PC, Mac or Linux box, although installation for Linux and OSX is considerable easier than for Windows.

You can download the latest version of Git here Once you have the files, try this quick guide to get you started with the installation process. For Windows users, this step-by-step visual guide should be helpful. Mac users, try this guide found on GitHub

Getting Started

Once you have Git installed, you can create your repository. To turn an existing folder into a Git repository, use the following commands in your Terminal or Command Prompt window:

cd path/to/project
git init
git add .
git commit

What you’re telling Git to do is:

• Initialize this directory
• Add everything in it – all files and subdirectories
• Commit or store, all current changes in the repository

If you hate the command line you can also do this using the Git GUI. It’s not the prettiest thing you’ve ever seen, but it’s there if you need it.

A Sample Git Workflow

I’m currently using Git on a Mac to work on a web application with multiple web developers. We have a “master” version of the code that we push our files to, and we each run a full copy locally. On any given day, my workflow goes something like this:

1. Fire up Terminal. Start up my local mysql database (so the application we’re building can run locally on my machine).
2. Use Terminal to check out the latest changes by using the “git pull” command. This gets me all the changes made by other team members and checked into our master repository.
3. Open the project in TextMate and make my changes.
4. Commit changes and add my notes. This only commits them locally. I commit frequently, probably ten or more times a day. This helps keep me on track.
5. Push my changes to the master repository using “git push”. Now other team members can check out and see my changes. You should do this at least once a day or after any major addition.

All of these actions can be done easily through the Terminal window, but I’m a visual kind of girl. For that reason, I use GitX, a Git gui for OSX, to make my commits. I still push and pull through Terminal, but GitX makes it easy for me to organize my commits and wrap my head around what I’m doing.

At the top, it highlights what change was made to the files. In the lower left is your list of Unstaged Changes. To commit them, you drag one or more files to the “Staged Changes” area on the right, type in your commit message, and hit the Commit button.

If I flip to the tree view, I can see what has been pushed to the repository. If my files were not current with the master files, the green and blue tags at the top would be out of sync. GitNub offers a similar Mac-style interface.

There’s also a great TextMate bundle available. With it, you can push, pull, commit, and more without ever leaving TextMate. It’s extremely efficient.

Learn More

Git Cheat Sheet

Above: Zack Rusin’s Git Cheat Sheet

I’m still a newbie to Git myself, so I’ve only scratched the surface as to what you can do with it, but I’ve definitely seen the light when it comes to version control, and am glad I finally got on the bandwagon.

To learn more about using Git, check out these great resources:

Intros To Git

Getting To Know Git
Wikipedia entry on Git
Why Git Is Better Than X
Linus Torvald’s TED talk on Git
A Tour of Git: The Basics
Git Ready

Cheat Sheets/Tips

37 Signals Git Resources
Git For The Lazy
The Git User Manual
A Gaggle of Git Tips
GitHub’s Git Cheat Sheet
Git Magic

Intros to Version Control

Version Control For Designers
A Visual Guide to Version Control
Wikipedia entry on Revision Control
Choosing a Distributed Version Control System
I Wonder What This Button Does (A List Apart)

Written exclusively for WDD by Mindy Wagner. She is a web designer at Viget Labs and has worked in both print and web design for over 8 years. She has a degree in Electronic Media Art and Communication from Rensselaer Polytechnic Institute.

Do you use Git or other software for version control? Please share your experience with us!

WDD Staff

WDD staff are proud to be able to bring you this daily blog about web design and development. If there's something you think we should be talking about let us know @DesignerDepot.