The Librarian’s Arsenal: Git & GitHub

This post originally appeared on Information Space, the blog of the iSchool at Syracuse University, on 10 October 2012.

Prompted by a fantastic talk given by the iSchool’s own Michael Fudge, I’ve been exploring Git, GitHub, and the ways librarians can benefit by using a version control system.
Librarians should know how to code. This isn’t news; coding is simply another form of literacy. This post won’t spend any time rehashing the reasons that coding is a vital skill in today’s society. Learn it, teach others, improve society.
What’s this “Git” thing, anyway?
Git is a tool for keeping track of code–any type of code, from HTML/CSS to high-level programming languages. Specifically, Git provides a “version control system” that allows you to save a file directory (called a “repository”) exactly as it stands at a certain point in time. While this is useful if you want the ability to revert to a previous version of the various documents in the repository, the real strength in Git lies in the ability to branch your code.
“Branching” is a way to create a figurative “tree”, which splits the saved files for any number of reasons down two or more paths. For example, it’s possible to have a branch of a website that is the current “production” version, and another up-and-coming “development” branch. Or perhaps there’s a branch for a current project, and each person working on the code has a slightly different way of approaching the problem. By merging branches back together, the best possible code can be distilled.
Ok, but how does GitHub factor in?
GitHub takes the ideas behind Git and makes them social, providing cloud storage for repositories and allowing for collaboration between coders of all levels. Most exciting, GitHub expands the branching abilities of Git into “forking,” which allows users to clone code into their own repository. Some librarians might be familiar with David Darts’ PirateBox, and Jason Griffey’s fork of the source code that resulted in the LibraryBox. Forking code makes it possible for librarians to tailor other projects to the specifications we need. It’s a shared, open-source way of co-creating content that librarians should take advantage of.
So why should librarians care?
Librarians can be some of the best liaisons between “geeks” and people who don’t code–we’re naturally positioned at the intersection between technology and the analog world. Tools like Git can help us facilitate when we’re managing multi-headed projects with coders, information architects, administrators, and the public. GitHub is even better because it allows us to open up our code, getting input from others as we build systems to use for the future.
Git lets people keep track of their code, and by having excellent revision management, it’s a lot easier to recover from mistakes, allowing people to get in and play with their code with less fear. Librarians get to have more control when projects are done within a Git system. The openness of GitHub is even better, and plays strongly to librarianship’s core values. As transliterate librarians operate in our program-or-be-programmed world, tools like Git & GitHub help us keep our work transparent, which can help showcase our value to the public.
Git and GitHub both deserve a place in the arsenal.