The basics of contributing to open source with GitHub / GHC14

My first session after the plenary opener was about how to use GitHub, presented by John Britton.  I was interested in getting some better insight into effective use of Git, a distributed version control system, so I could eventually move some of my own projects to my (thus far unused) GitHub account.

GitHub Office / Ben Scholzen 

Although I did find the session useful, it unfortunately moved a bit too fast and with demos that were hard to make out on the big screen due to the high resolution of the image.  I tried to keep up while trying things out, but quickly found myself lost.  (Funnily enough, it was when John started demoing Git from the command line that I was really able to get a handle on things.)  I'll share some of trickier bits I was able to figure out during the session along with my own research below.

I admittedly still get confused by Git since I haven't used it for any of my own projects.  The key thing to sort out is the workflow, which is different from version control systems like CVS and SVN:

• The first step in making changes to an existing project is to clone it.  This fetches a repository that you don't yet have locally.
• Next, you can checkout a new branch, giving it a name and activating it (or, if the branch already exists, just switch to it).  There is some useful discussion about the difference between clone and checkout here.
• After making some changes to files or adding new ones, you can use git status to review those changes.
• If there's a new file that you want to be tracked by Git, you need to add it.
• When ready, you can commit your current set of changes to the repository, creating a snapshot of sorts.
• Finally, when you are ready to send your local snapshot to your Git repository, you push.

Another issue that confused me terribly is the idea of a pull request.  GitHub lets you "fork" somebody else's project, which basically means making a branch within your own GitHub account.  You can work on your forked project and make whatever changes you want without affecting the original owner's project or requiring their permission. Then, you can make a pull request.  The name of the action suggests to me that you are requesting to pull changes from somebody else's project, but in fact you are requesting that the owner of a project pull your changes.

If you aren't familiar with branching and merging, this article might be useful.  You might also like Code School's interactive lessons on GitHub to get a feel for the system overall.

One last thing: if you are a student, you must check out this recently announced student pack, which includes access to a free micro account on GitHub (this lets you have private repositories).  Awesome!!