Resource: Forking, Fetching, Pushing, Pulling

Scholars’ Lab.

Even though a lot of open source projects encourage folks to look at the code and modify it, they don’t just let anyone add anything back to the original project. Projects usually have one or several people with direct commit access, who don’t need permission to do commits. This doesn’t mean you can’t contribute to the project; you’ll just need to get your own copy of the code, make changes there, and then send them back to the original project for review.

Contributing to an open source project can be a lot of fun, and Github makes that process pretty easy. Still, there are a few steps to keep in mind to make sure your workflow is sound and your contributions have better chances of getting accepted. To follow along, you’ll need an account on Github, and you’ll need to have git installed on your machine. This post won’t go into detail about using git, but if you’re not familiar with it, check out Eric’s post on Teaching Git and the git resources we’ve collected for the Praxis Program.

For this post, I’m going to use Omeka as our example, since I’ve been sending a few pull requests their way as I’ve been developing themes for their upcoming 2.0 release. But the process I describe can easily be applied to many other projects. (In fact, Scholars’ Lab would love for anyone to fork any of our repositories and send stuff back.)