There are certain software development techniques or tools that are not strictly part of the AP Computer Science curriculum that I think are valuable for students to learn about and practice in my class. Two years ago, I incorporated pair programming. Last year, I added test-driven development and JUnit. This year, I made [GitHub](http://github.com/) an integral part of the course.
I want students to be aware of and appreciate the value of source control management. GitHub was the obvious choice as they are [supportive of education](https://education.github.com) and is mostly likely the specific tool that students will encounter.
After consulting with a couple former students more familiar with GitHub than I, I decided to create a [repository for each unit in the course](https://github.com/nnhsapcs201415). At the start of each unit, students fork that unit’s repository and clone it to their desktop. They perform these operations through the GitHub web site.
Throughout the unit, I encourage students to put all of their code in their forked repository and frequently commit and sync. This provides students with all of the typical advantages of source control: they can more easily work at both school and home, and they can revert to an earlier version of code if a project goes astray.
At the end of the unit when students have completed their summative lab, they issue a pull request to submit the lab. They then submit the URL to this pull request via the [Canvas](http://www.instructure.com/k-12/) assignment that I created for the summative lab.
I created a video tutorial that captures the student workflow:
The student workflow works well except when they accidentally generate merge conflicts by not keeping home and school synced.
While exposing students to GitHub is enough of a benefit, this particular workflow is extremely efficient from the perspective of me evaluating their summative labs.
I [still use Canvas’s SpeedGrader](https://pedagoguepadawan.net/216/greatest-benefit-of-canvas/) to keep track of who has submitted the lab and to provide detailed feedback to students. In previous years, I had students submit a zip file of their entire project folder. The link to their pull request is much more efficient. My workflow for evaluating their lab is the following:
1. Click on the link in SpeedGrader to open the pull request page in another tab.
2. Click on the “Check out this branch in GitHub for Mac” icon which does exactly that.
3. Open the BlueJ project file for the summative lab, read the code, read the docs, run the project, and provide feedback via SpeedGrader.
4. Close the pull request.
5. Run the following script which switches back to the mater branch and removes all traces of the student’s pull request:
git reset --hard git clean -xdf git checkout master
6. After evaluating all of the labs, I list all of the branches that I checked out:
git branch --list
7. I then delete each of these branches:
git branch -D pr/xx
While the above may seem like a lot of steps, there is very little overhead and it is much more efficient than my previous workflow.
I’m embarrassed to admit that there is another advantage of these GitHub repositories for each unit that I didn’t utilize until this past unit. While making notes to myself about where we had stopped in one class period where I was modeling how to write a certain algorithm, it struck me that I can create branches for each class period. I now create a branch for each class period and, when I demonstrate how to write some code, I commit and sync that branch with some helpful notes to myself at the end of each class period. The next day, I switch to the corresponding class’s branch, read my notes, and we start right where we stopped.
If you have any suggestions on how I can improve my students’ workflow or my workflow, please share. If you have been thinking of incorporating source control management into your computer science class, I encourage you to take the plunge. Your students will learn a very valuable skill!