Coming to academia from industry, I am a strong proponent of teaching useful career skills to undergraduates, especially when it can be done in a way that enhances or reinforces core CS concepts. Using a source control system for managing assignments has always been near the top of my wish list in this regard. A few of my like-minded colleagues have used externally hosted websites and Subversion (SVN) for managing classes with some success. I wanted to experiment with a system that would integrate with what our department’s current workflow and technology.
This semester our administrator and I collaborated to create a set of Git repositories for my senior level Interface Design and Technology class. The repositories replaced a set of script files on a department Unix server that have been used for several years to help automate paperless submission of homework and programming assignments. We set up a separate repository for each student in the class, and one for each of the project groups. The directory containing each repository was owned by a Unix group that consisted of the student (or students, in the case of project group repositories) and myself. Each repository was created “bare” — no working directory — and “shared” to act as an integration point for the student’s work. Each student cloned the repo for themselves and their group, and I cloned all of them to my workstation.
Students would push each assignment to the shared repo. I would pull the repo, grade the assignment, commit the changes, and push the grades back to the repo.
Despite inevitable problems with permissions, branches, and conflicted merges, I consider the experiment a success. I was able to create simple scripts to automate much of the pulling and pushing, though there are several more I will make next time to support some of the grading tasks. There are a few important things I learned.
First, notification is important for this environment. We had not set up e-mail notifications, and I ended up sending group messages to the class when grading was complete. It was also not always clear to the students when they had successfully pushed their work to the correct branch in the shared repo.
Using ssh keys for authentication is virtually a necessity for this setup. I typed my password more times than I care to remember over the course of the semester. My dream for our CS program would be to spend the first day of the intro class for majors setting up ssh keys and an individual Git repo. There is an open question whether each class would be better represented by a separate repository or a branch in the student’s master repo, but either way a graduating senior could take all of their school work when they leave, with a complete history of its creation.
As an aside, one of our groups became so interested in some of these issues that they created an application to help beginners master the system and support the functions necessary for our workflow. For their penultimate project, they added automated integration using Buildbot with results (success or failure) integrated into the system. This is one step toward my long term goal of using test cases to serve as both specification and instant grader for assignments, but that is a discussion for another day.