Melody Kramer

Learning Github Without One Line Of Code

06 Apr 2015

I’ve heard from a lot of people who have said they want to learn more about GitHub and are totally put off by the learning curve. That makes sense, because GitHub seems to have been built for robots by other robots: it’s tough, it’s not user-friendly, and it’s not intuitive.

Having gone through the steep learning curve not-too-long ago, I will try to explain: GitHub is basically a way for coders to keep track of different versions of code that have been touched by multiple people. You can think of GitHub as a wiki, but for code.

Let’s think of it in terms of a paragraph: I can add a sentence to a paragraph. You can add a sentence and recommend that it gets added to the same paragraph. But your sentence needs to be approved by someone before it is incorporated to the paragraph.

The easiest way to learn GitHub, I think, is to start with words instead of code. Lots of people have used GitHub to communally edit documents, which is a really good way to learn the language of GitHub and not touch one piece of code.

  1. Here’s the definitive list to lists of information on GitHub (for example: lists of recipes, dissertation tips, corporate logos, beautiful documentation, free programming books, free programming courses)

  2. GitHub lists are communally edited. Anyone can add to it (instructions below.) This makes it much easier to keep it up-to-date and to keep it relevant.

  3. So let’s build a list together. Here’s the list I’ve started for public media. It’s not very complete yet. In fact, the framework and architecture isn’t even complete. But that’s the beauty of GitHub. It’s not a solo project. Anyone can add to this, and make it better.

  4. It’s actually a really good first project to try on GitHub, because there’s no code involved. To improve that page:

a. create a GitHub account

b. Click on the button FORK in the upper right hand corner of this page.

c. Make any changes you’d like to the document. (You can see recommend changes under issues, which is code for “things Mel thinks need to be changed.”)

d. Submit a pull request — which is a fancy way of telling me you want to make a change — by clicking on the button marked “Create a new branch for this commit and start a pull request.”

e. Wait for the changes to be incorporated.

And all of this is public, which is what public media should be (and why it should all be collected together, by the public and for the public.)

Want more GitHub instructions? I cowrote a tutorial which is more advanced than necessary for this project but will be useful should you decide to use it in the future.

Have a good one,


PS: Added bonus: a good first step in getting everyone in public media comfortable with git so stations can then invite communities into contribute on projects (aka my Nieman project).

this was originally a newsletter:

Leave a comment
Fix my typos