How to GitPosted: March 18, 2013 | Author: Eric Phetteplace | Filed under: coding, library, tutorial, version control | 6 Comments »
We have written about version control before at Tech Connect, most notably John Fink’s excellent overview of modern version control. But getting started with VC (I have to abbreviate it because the phrase comes up entirely too much in this post) is intimidating. If you are generally afraid of anything that reminds you of the DOS Prompt, you’re not alone and you’re also totally capable of learning Git.
But why should you learn git?
Because Version Control Isn’t Just for Nerds
OK, never mind, it is, it totally is. But VC is for all kinds of nerds, not just l33t programmers lurking in windowless offices.
Are you into digital preservation and/or personal archiving? Then VC is your wildest dream. It records your changes in meaningful chunks, documenting not just the final product but all the steps it took you to get there. VC repositories show who did what, too. If you care about nerdy things like provenance, then you care about VC. If co-authors would always use VC for their writing, we’d know all the answers to the truly pressing questions, like whether Gilles Deleuze or Félix Guattari wrote the passage “A concept is a brick. It can be used to build a courthouse of reason. Or it can be thrown through the window.”
Are you a web developer? Then knowing Git can get you on GitHub, and GitHub is an immense warehouse of awesomeness. Sure, you can always just download .zip files of other people’s projects, but GitHub also provides more valuable opportunities: you can showcase your awesome tools, your brilliant tweaks to other people’s projects, and you can give back to the community at whatever level you’re comfortable with, from filing bug reports to submitting actual code fixes.
Are you an instruction librarian? Have you ever shared lesson plans, or edited other people’s lesson plans, or inherited poorly documented lesson plans? Basically, have you been an instruction librarian in the past century? Well, I have good news for you: Git can track any text file, so your lessons can easily be versioned and collaborated upon just like software programs are. Did you forget that fun intro activity you used two years ago? Look through your repository’s previous commits to find it. Want to maintain several similar but slightly different lesson plans for different professors teaching the same class? You’ve just described branching, something that Git happens to be great at. The folks over at ProfHacker have written a series of articles on using Git and GitHub for collaborative writing and syllabus design.
Are you a cataloger? Versioning bibliographic records makes a lot of sense. A presentation at last year’s Code4Lib conference talked not only about versioning metadata but data in general, concluding that the approach had both strengths and weaknesses. It’s been proposed that putting bibliographic records under VC solves some of the issues with multiple libraries creating and reusing them.
As an added bonus, having a record’s history can enable interesting analyses of how metadata changes over time. There are powerful tools that take a Git repository’s history and create animated visualizations; to see this in action, take a look at the visualization of Penn State’s ScholarSphere application. Files are represented as nodes in a network map while small orbs which represent individual developers fly around shooting lasers at them. If we want to be a small orb that shoots lasers at nodes, and we definitely do, we need to learn Git.
Alright, so now we know Git is great, but how do we learn it?
It’s As Easy As
git rebase -i 97c9d7d
Actually, it’s a lot easier. The author doesn’t even know what
git rebase does, and yet here he is lecturing to you about Git.
First off, we need to install Git like any other piece of software. Head over to the official Git website’s downloads page and grab the version for your operating system. The process is pretty straight-forward but if you get stuck, there’s also a nice “Getting Started – Installing Git” chapter of the excellent Pro Git book which is hosted on the official site.
Alright, now that you’ve got Git installed it’s time to start VCing the heck out of some text files. It’s worth noting that there are software packages that put a graphical interface on top of Git, such as Tower and GitHub’s apps for Windows and Mac. There’s a very comprehensive list of graphical Git software on the official Git website. But the most cross-platform and surefire way to understand Git and be able to access all of its features is with the command line so that’s what we’ll be using.
So enough rambling, let’s pop open a terminal (Mac and Linux both have apps simply called “Terminal” and Windows users can try the Git Bash terminal that comes with the Git installer) and make it happen.
$ git clone https://github.com/LibraryCodeYearIG/Codeyear-IG-Github-Project.git Cloning into 'Codeyear-IG-Github-Project'... remote: Counting objects: 115, done. remote: Compressing objects: 100% (73/73), done. remote: Total 115 (delta 49), reused 108 (delta 42) Receiving objects: 100% (115/115), 34.38 KiB, done. Resolving deltas: 100% (49/49), done. $ cd Codeyear-IG-Github-Project/
$ above is meant to indicate our command prompt, so anything beginning with a
$ is something we’re typing. Here we “cloned” a project from a Git repository existing on the web (line 1), which caused Git to give us a little information in return. All Git commands begin with
git and most provide useful info about their usage or results. In line 2, we’ve moved inside the project’s folder with a “change directory” command.
We now have a Git repository on our computer, if you peek inside the folder you’ll see some text (specifically Markdown) files and an image or two. But what’s more: we have the project’s entire history too, pretty much every state that any file has been in since the beginning of time.
OK, since the beginning of the project, but still, is that not awesome? Oh, you’re not convinced? Let’s look at the project’s history.
$ git log commit b006c1afb9acf78b90452b284a111aed4daee4ca Author: Eric Phetteplace <email@example.com> Date: Fri Mar 1 15:27:47 2013 -0500 a couple more links, write Getting Setup section commit 83d92e4a1be0fdca571012cb39f84d86b21121c6 Author: Eric Phetteplace <firstname.lastname@example.org> Date: Fri Feb 22 01:04:24 2013 -0500 link up the YouTube video
We can hit Q to exit the log. In the log, we see the author, date, and a brief description of each change. The terrifying random gibberish which follows the word “commit” is a hash, which is computer science speak for terrifying random gibberish. Think of it as a unique ID for each change in the project’s history.
OK, so we can see previous changes (“commits” in VC-speak, which is like Newspeak but less user friendly), we can even revert back to previous states, but we won’t do that for now. Instead, let’s add a new change to the project’s history. First, we open up the “List of People.mdown” file in the Getting Started folder and add our name to the list. Now the magic sauce.
$ git status # On branch master # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: Getting Started/List of People.mdown # no changes added to commit (use "git add" and/or "git commit -a") $ git add "Getting Started/List of People.mdown" $ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: Getting Started/List of People.mdown # $ git commit -m "adding my name" $ git status # On branch master nothing to commit, working directory clean $ git log commit wTf1984doES8th1s3v3Nm34NWtf2666bAaAaAaAa Author: Awesome Sauce <email@example.com> Date: Wed Mar 13 12:30:35 2013 -0500 adding my name commit b006c1afb9acf78b90452b284a111aed4daee4ca Author: Eric Phetteplace <firstname.lastname@example.org> Date: Fri Mar 1 15:27:47 2013 -0500 a couple more links, write Getting Setup section
Our change is in the project’s history! Isn’t it better than seeing your name on Hollywood Walk of Fame? Here’s precisely what we did:
First we asked for the
status of the repository, which is an easy way of seeing what changes you’re working on and how far along they are to being added to the history. We’ll run
status throughout this procedure to watch how it changes. Then we
added our changes; this tells Git “hey, these are a deliberate set of changes and we’re ready to put them in the project’s history.” It may seem like an unnecessary step but adding select sets of files can help you segment your changes into meaningful, isolated chunks that make sense when viewing the
log later. Finally, we
commit our change and add a short description inside quotes. This finalizes the change, which we can see in the
log command’s results.
I’m Lonely, So Lonely
Playing around with Git on our local computer can be fun, but it sure gets lonely. Yeah, we can roll back to previous versions or use branches to keep similar but separate versions of our files, but really we’re missing the best part of VC: collaboration. VC as a class of software was specifically designed to help multiple programmers work on the same project. The power and brilliance of Git shines best when we can selectively “merge” changes from multiple people into one master project.
Fortunately, we will cover this in a future post. For now, we can visit the LITA/ALCTS Library Code Year‘s GitHub Project—it’s the very same Git project we cloned earlier, so we already have a copy on our computer!—to learn more about collaboration and GitHub. GitHub is a website where people can share and cooperate on Git repositories. It’s been described as “the Facebook of code” because of its popularity and slick user interface. If that doesn’t convince you that GitHub is worth checking out, the site also has a sweet mascot that’s a cross between an octopus and a cat (an octocat). And that’s really all you need to know.