Tech Interlude: Git to the Hub

Yesterday, thanks to a great tutorial from the Library Code Year Interest Group, I completed my first successful project on GitHub.

If you don’t know what GitHub is, it’s a web-based open source repository for collaboration on software development.   It uses the Git revision control system to track a project’s revision history.

This tutorial used some very basic functions of Github – forking (copying) and cloning a project to your local server, editing the project, committing the project back to your remote GitHub access, and then committing it to the larger project.

You do have to have a level of familiarity with programming, and comfort with command lines in a terminal window.  If you’re a programming novice, I would not recommend this.

The tutorial (written by Eric Phetteplace) goes into more depth, but there are six basic steps to the project.

  1. Installing Git – this took the longest, if you can believe it.  This is the Curse of the Mac – the recommended product due to ease of install, xCode, is a Big File (1.65 GB).  
  2. Creating a GitHub Account
  3. Forking and Cloning the Repository You Will Be Working On – In short, this is making a local remote copy of the repository on your account, and then cloning that copy on to your hard drive.  I do have some comfort with terminal applications, but I still got stuck here due to my limited experience with terminal commands, particularly with navigating the project folders on my hard drive. With some persistence, I got things to work. (I also discovered later there are GitHub GUI interfaces, like this one for the Mac, which look great but I feel like are the easy way out for the novice.  Has anyone used them?)
  4. Editing the Repository – in this case, adding your name and a link to your GitHub account to a list of people.
  5. Committing Your Changes Back to the Remote Github Server – taking your locally saved changes back up to Github
  6. Sending a Pull Request – this is the notification to the project managers that your changes are complete and ready for review and (hopeful) inclusion.

I was so excited when I saw my changes on Github, and when I sent the pull request, I had to take screenshots (you’re going to want to click on them to make them larger).

Githubstep5This is the result after the commit request that pushes the changes back to Github.  I was in glee at what a few command lines would do, especially having little experience in writing terminal commands.  



The request to have my changes committed to the main project. It’s out of my hands now….


Whee!  I’ve been approved!  (Yes, I saved the e-mail.  And yes, that is inbox zero on your left.) 

I wish I had Git and Github in one of my previous jobs at a law firm, where I was responsible for our website.  I was the final step in reviewing changes put on the site, like when an attorney adds a publication or a new bar admission.  The process was very analog – the attorney had to submit their changes on a website form (either by themselves or through me), those changes went through administration, then to IT (who implemented them), then to me for final review.  If I found something wrong, it went back to IT – and sometimes languished there when IT had other, higher concerns.  Attorneys would get frustrated when their request to have their admission to New York state not show up on their site, and there was nothing I could do about it (except come begging to IT baked goods in hand). 

With Git and Github, I could track the project on the site, thus receiving notifications of changes, i.e. when IT made a change to the site.  I could download, review the HTML files and then make whatever changes I needed to make – fixing spelling, closing tags, etc.  I can then commit the changes back, have IT integrate them into the main project and bring the site live.

I would also be remiss if I did not commend Eric for a finely written tutorial and companion video tutorial.  Both were highly detailed and worked well together – if I did not understand something in the written instructions, I could go back to the video and watch Eric visually step through the task.  This is how the Python class I took through Coursera/University of Toronto taught, and it was utterly effective.

I’m looking forward to whatever else Code Year does with GitHub.  It looks like they want to do a web design project – and when you look at what I wrote above, it’s no surprise I am way too excited over that. 🙂

Oh, and if you want to follow me on Github, here I am.

Bookmark and Share

This entry was posted in LIS, Tech. Bookmark the permalink.

4 Responses to Tech Interlude: Git to the Hub

  1. pbinkley says:

    Note that installing Git with Homebrew (as mentioned in the tutorial) is much easier, and doesn’t require the huge download (and all the space that XCode is now taking up on your hard drive). If you’re not using Homebrew you should check it out.

    If you try out the GUIs, I hope you’ll post about your experience. Like you I’m using the command line tools as a way to try to bake Git concepts into my brain but I mean to get to know the GUIs at some point.

    • librariankate7578 says:

      Thank you for the suggestion – I’ll check it out when I get home. Fortunately, I had the space on my MBP for the xCode. 🙂

      • Andromeda says:

        Homebrew has the added advantage that it’s maintained by mistym, whom you see around in IRC 🙂 I’ve only dabbled in it but it seems pretty slick.

        That said, for all that XCode is a pain and takes forEVer, in my experience it contains all kinds of weird important stuff that you need to do development — if you don’t have it you keep running into bizarre, incomprehensible bugs whose error messages are 7589327 steps removed from the actual error, and then you install XCode and they go away. Installing XCode is a painful way to get git, but it’s worth doing. (and then install all the OTHER dependencies you will ever need, for anything, with homebrew or pip or something.)

  2. With regard to your concern about the github gui being an ‘easy way out’ — the github gui totally is not cheating and people should use it. I’ve been using version control systems for two decades now and github’s gui is the best version control GUI I’ve yet seen and the first I’ve found suitable for daily use. I’m a “real” coder and I use it pretty much daily.

    When you don’t need the intricacies of weird rebase options and ugly merges, it’s totally adequate and usable. And if you do find yourself needing those things, you can mix and match: Unlike many version control GUIs it doesn’t have hidden state or secret actions, so it maps pretty one-to-one to the command-line commands and is good way to build intuition around them.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s