For the last several years I have been using a version control system for all my work files, and by work files I mean everything, not just code. All my design files, layouts, Photoshop documents, and everything else gets committed to a repository of some sort so I am always able to keep track of all the changes that are made to a document. Everything I submit a mockup to a client the changes are committed so I can always get back to that point no matter what. I don’t have to save multiple versions of the design in order to have this complete history.
It also, even more importantly, saves me from myself when I make stupid mistakes—as in getting a file that was buried in a folder that you thought only had unimportant stuff and got thrown away but you really ended up needing it.
If you are a designer, I highly recommend some sort of version control system. It is great (though it can be a little difficult to figure out if you aren’t also a developer).
Up until recently, I was using SVN as my vcs of choice. It worked pretty well. I kept a remote repository on my local server (an old macbook that doesn’t have a battery anymore that is sitting behind the Wii in our living room) and checked out the needed folders onto my macbook pro. Whenever I got to a point where I wanted to commit the changes, I would send the changes to the remote repository and know that my server was backed up offline and I would always have all versions of my work files even if my house blew up today.
It was pretty great, unless I decided to move my folder hirearchy around a little within the repository. All my project files were in a single repository which made it easy to keep track of things, but a nightmare to manage the repository itself.
Recently I decided to give git a try. It is a completely different take on the vcs in that you don’t just check out the repository, you clone it. Your local copy of the project is a clone of the entire repository and all the files needed for it are there. I had to make some adjustments in my thinking related to workflow. Now each project is its own repository rather than being part of a larger one. Also, I don’t have a copy of the repository on the server until I am done with the project and ready to archive it. And to archive it I just copy it to the server.
I do miss the fact that the server is the main copy of the repository. It always felt cool to me, when I was using svn and my repository was on the server, that all I had to do to archive a project was delete it. As long as all the changes were committed then I was good to go.
But, to be honest, that is the only thing I miss from svn.
Everything else, is WAY better in git. Here are just some of the things that I love:
- Items in the repository aren’t bound by their folder location. If I want to move a file, I just move it. If you want to change the location of a file in SVN, you have to do it at the repoistory level (not just your checked out copy) because othewise SVN doesn’t know the history of that file. In git, the location of the file is just one attribute of it. If the location changes, then all git does is update that meta data on the file. It knows, automatically, what you did and the complete history of the file remains intact.
- All the information for git is located in one spot in the project’s root folder. In SVN, the hidden files that help it keep track of everything are located in each folder. This makes it a huge headache when it comes time to move or delete folders. Anything like that, again, has to be done at the repository level through SVN. It forced me to think about the repository, whereas with git, I just think about my work.
- Gitbox. It’s a great GUI for git. I used Cornerstone for SVN and it worked great, but Gitbox is super clean and it works great.
- Searching for a file back through the history is super easy with Gitbox. I can create a file and then delete it, and find it again with no effert.
So my trying out of git turned into a full on switch and it has worked great for me. Couldn’t be happier.