aamir virani

A Super Quick Guide to Using Git

While thinking about how to organize projects on my home machines, I decided to look into Git, a version control system like CVS and Subversion (SVN). Unlike those two, however, Git is distributed, which means you can have multiple repositories for the same project, and/or only a local one to handle your stuff.

You can use Git a lot like Subversion with one major benefit: you can do local check-ins without having to branch, synchronize, and create remote copies of your own sandbox.

Of course, this means you have to learn yet another set of syntax. A really good primer is a crash course on Git for SVN users, but here are the key things I learned and found to get rolling fast.

So let’s just assume you’re creating a project in directory local_dir. You already have a bunch of files and you want to sync up. You also have a remote server my_server. Here’s what you do.

First, go into the local_dir directory and:

• git init – sets up the git files for tracking locally
• create and edit a text file called .gitignore – on each line place files you want to ignore, like DS_Store and *.tmp files, etc.
• git add . – tells git you want all files (recursively) as part of the next commit
• git commit -m “initial checkin blah blah” – tells git to commit with the given message

At this point you’re locally ready to go. If you don’t want to work on multiple machines or synchronize to the cloud, have fun!

Otherwise, you should now go to your server and set up a place for your files to live in remote_dir:

• mkdir remote_dir
• cd remote_dir
• git –bare init – sets up git in this directory with no initial working copy

Now you go back to your local machine and tell it about your remote server:

• git remote add origin account_name@server.com:remote_dir – tells git how to ssh to your remote repository
• git push origin master – tells git to send your local copy to the server – magic!

You may want to edit .git/config so that you can quickly push and pull files by adding the following lines to this file:


[branch "master"]
  remote = origin
  merge = refs/heads/master


This will mean you can use the following commands to synchronize to and from the remote server:

• git push – send local copy to the server
• git pull – get server updates into local copy

Finally, if you want to work on other machines (or have someone else join you in your work), all they have to do is:

• git clone account_name@server.com:remote_dir – copies the remote repository to your local machine

Voila – you’re ready to go!

How do you know if your code is fast enough?

One of the big pains I’ve seen while at PR and X is dealing with customers, managers, and critics who go off on performance.

• When you click here, it takes too long!
• When you start up, it takes forever!
• When this page loads, I can go get a cup of coffee and it’s still loading!

All are valid concerns, but it gets a little ridiculous when you hear someone say “it needs to be 0.2 seconds faster” or “we have to be at least as fast as before even though we’re doing 10 times more processing”.

Perception, a qualitiative measure, is more important than quantitative measurement.

Given that Internet connection speeds vary, that client computers can be a few years old, and that humans can be sedated or caffeinated, it’s even more important to move beyond simple clock-watching.

David Weiss discusses performance on his blog and mentions a classification scheme for timing perception:

• Instantaneous (0.1 to 0.2 seconds)
• Immediate (0.5 to 1.0 seconds)
• Continuous (2 to 5 seconds)
• Captive (7 to 10 seconds)

So instead of simply whining about how things have gotten slower by 0.1 seconds, determine where your feature (broken down into actions or features or events, but that’s another topic) falls. Now, are you within range?

The other difficulty is deciding which category the feature should be in. This is where user studies matter. Your boss is not the ultimate arbiter. You are not the ultimate arbiter. Make sure your typical set of users would be happy with your choice by faking time delays in a mockup.