What You Think You Know
You know how to use a computer, right? Obviously that’s true since you’re reading this, but that doesn’t mean you know how a computer works. You probably have some idea that electricity, circuits, binary and other computer stuff are working together to make the thing run, but for most people there is a little bit of magic involved. And when somebody asks you to explain how something like a computer works, it suddenly becomes abundantly clear how much you don’t know about these things you use all the time. In similar fashion, this is how I understood GitHub. So I wanted to dedicate this blog to discussing how my understanding of GitHub, a tool that I’ve used throughout the CHI fellowship, has changed with teaching it in a workshop. There is still a little bit of magic involved for me, but considerably less so.
What is GitHub?
GitHub is a distributed version control system. This is a fancy way to say that the files for a project you’re working on are distributed to every computer working on the project. This has the advantage of creating multiple backups, while also allowing everybody involved in the project to work offline. The main advantage of GitHub, however, is its version control.
Everybody has practiced some form of version control. For instance, you’ve probably made multiple word files called something like “rough draft 1”, “rough draft 2”, “rough draft 3” and so on. These multiple files describe different versions of a file, that may be useful to go back to. How many times have you taken out a section, later regretted it, and then had to rewrite the entire thing because you can’t get it back? Having previous versions of your work helps to remedy this situation, especially in software development. This is where git comes into the picture.
Git is a distributed version control system that allows multiple people to work on a project while also tracking all of the changes those people are making to a project. There are multiple systems for this type of version control, but git is by far the most popular. GitHub is built upon git, and has become one of the most popular ways to collaborate on the development of code.
GitHub Workshops
Within this past month, I have led three GitHub workshops. These workshops were designed to teach anthropology students with no background in software development how to collaboratively work on a project using GitHub.com. This required them to create an HTML file and edit it with a partner working on one repository within GitHub. This requires the use of Github.com, GitHub Desktop and Atom text editor. In preparation for these workshops, I had to learn GitHub better than I had ever learned it before.
Though I had used GitHub for about a year and half, the basic principles were still not super well known to me after a year of using it. Sure, Ethan taught it to me, but I all I knew was that I had to press these buttons in a certain order to get them to appear in my online repository. That’s being a little harsh. I kinda understood it, much like how I understand that electricity, circuits and binary are in my computer. But now I was required to tell people how the electricity runs through the circuits giving us binary that translates to what we see on screen.
I started off by going back to my notes on GitHub, and researching any websites that had insight into how the whole thing worked. After getting a handle on things, I taught the GitHub workflow to my fellow staff at LEADR. This helped me see what parts of the process of the GitHub workflow were not super clear. I was also able to build off of the work of another CHI fellow, Brian Geyer, who had taught the workshop before me. Using his lesson plan and feedback, I was able to develop a diagram I thought would help to clearly visualize what the students were actually doing with GitHub. The diagram can be seen below.
The Diagram
Step-by-step Breakdown
Apologies in advance if you are not already familiar with GitHub. There is a lot of terminology in here that I don’t cover, but you can check out this glossary for some help. This diagram describes the process that two team members will follow to make changes to their repositories. This uses color-coding, arrows, and GitHub Octodex mascots to represent the workflow. Arrows represent steps and are color-coded according to the software most responsible for those actions. They are also labeled by number and appropriate GitHub terminology. The various GitHub Octodex Mascots represent repositories. A breakdown of what each slide represents is as follows:
- I introduce the project, and the basics of GitHub. Additional slides were included for the workshop, but cut from the slide show for this blog post.
- The Workflow Diagram begins with an outline of the project. This is meant to scare them a little bit. There is a lot going on in GitHub and this outline doesn’t sugarcoat it. But I hope to reassure them that we will be taking this process step by step.
- The first action that the groups will be taking is forking a repository. Forking a repository allows them to have a copy of the project that they can freely edit themselves.
- The next step is cloning the forked repository onto their computer. I have separated this into two different paths since any number of people can clone the same repository. This makes a complete copy of the forked repository available on all of their actual computers.
- To reiterate that they cloned a copy of the repository, I replaced the laptop icons with the same GitHub Icon representing the forked and original repository.
- They are then able to make changes to the local repositories on their computer which I have represented as a Link Octodex and an Audrey Hepburn Octodex. Each partner will be making their own unique changes, hence the different Octodex.
- Once their changes have been made, they have to save those changes. The save is represented by the yellow-orange box.
- With their changes saved, the changes can then be staged and committed into their local repo. This means that the local repository will no longer represent the original repository or the repository that they forked.
- Once their local repository is set, they can push those changes back to their forked repository on GitHub.com. This new repository will reflect the changes made by both partners.
- In order to turn in their homework, they have to create a pull request that pulls the changes from their forked repository back into the original repository. This original repository will also have the changes from any other pull requests incorporated into it as well. That’s why the Link Octodex and Audrey Hepburn Octodex are partying with a bunch of other Octodex.
- Pull requests work both ways though! The forked repository can also pull all of the changes that were made to it back to their forked repository. This brings the party of Octodex mascots into both repositories where the process can begin anew.
- This slide points out where most of the work that they will be performing takes place. That is, in their forked repository and on their local computers.
- All of the interactions between their local repository and the repository on GitHub.com can take place in Atom text editor. The last slide spells out the specific steps that each person will take in order to make changes to and update their repository.
- Any Questions?
Conclusion
GitHub is something that every CHI graduate fellow has learned how to use. It wasn’t until I taught it, though, that I really began to grasp the explicit steps and reasoning for why it is that we are doing what we do. This has given me a newfound appreciation for GitHub and actually made me eager to use it for any project that I am able to. This blog post was largely an excuse to show off something that I think actually helped students to understand GitHub a bit better. This has at least been more successful than my CHI project, which is making progress, but PHP is hard. As soon as I am actually able to get something to appear on a webpage, I’ll get back to you.
Recent Comments