Phil Taylor recently tried to get up close and personal with git. He ran into difficulties, in no small part because he treated git like subversion, which it decidedly isn’t.

So in the interests of helping out anyone else out there with the same idea, that of wanting to try out something new in hopes of finding something better, here’s a quick-and-dirty glimpse at the way I use git around here.

Git isn’t SVN

The first thing to remember is that git isn’t svn. It’s not server-based. It’s a distributed code management system, meaning there could be potentially hundreds of repositories involved. You can use it just like svn, and have a single repository on a single server, but that would be like buying a minivan to drive two people around town. Of course, I have a repository on my server (and I honestly question the wisdom of anyone who doesn’t) but that’s only one repository, and it isn’t the first one I create.

I start out by creating the repository in my project directory on my development machine:

git init
git add .


Those two lines of code initialize an empty repository and then add every file in my current directory to the repository. The second line might instead be broken into several lines, if I didn’t want to add every file, but this is the quickest. (If there arejust a few files you want to leave out of the repository, you’ll want to check out how “git ignore” works.)

What About The Server?

Well, that’s all fine and good for your local development, but what about shared development? Don’t you need a server for that?

Yes, but you don’t need git on the server. After all, a git repository is simply files. All you really need is ssh access to the server.

ssh user@server.com
mkdir projectname.git
cd projectname.git
git init

The first line above gets you into the server, the second line creates the directory you’ll be using for your remote repository. The final two lines above create the empty repository. After those, you can log out and return back to your local machine.

You send your changes from your local repository to your remote one by using the “git push” command. But first you’ll need to tell git where the remote repository is:

git remote add origin user@server.com:projectname.git

This line creates a reference to a remote repository and calls it “origin” (it’s a longstanding custom that the main remote repository be called origin, but it’s not a necessity). It points “origin” at the remote repository we set up earlier.


git push origin master

This line pushes the changes in the local repository up to the remote one identified as origin.

Now you can continue to develop on your local machine, committing changes to your local repository, and once you’re finished, you can push all (or just some of) the changes up to the server.

(And yes, the obvious “git pull” would be how you bring changes pushed to the server by other members of the team down to your local repository.)

A quick sheet of “normal” git commands.

Git User’s Manual