I’ve used GitHub in classes for group projects to good effect; at Olympic College we have a Junior-year class, IS 302 Information Systems Integration, where teams each build competing websites, and then we choose a winner and integrate all of the teams into polishing and releasing the final website. GitHub has been instrumental in making that flow well. In addition to setting up a repository, teams have adopted the Wiki for documentation, Projects for electronic Kanban boards, and Issues for entering and tracking the (internal) user test results and follow-ups.
For that class, I set the groups up with a straight-forward repository use-model of master, individual branches, and pull requests and advise them to keep master publishable. Usually each team breaks this at least once, and learns the value of the advice. Students learn the basic workings of git, and then work through merge conflicts and set up procedures and policies to help keep their flow smooth. At least one group will crash-and-burn, restarting their local repositories several times while working through the GitHub model. I should say that so far, there has been almost no exposure to GitHub prior to IS 302, so they really have a lot to master all at once. By the end of the quarter they are fairly comfortable with GitHub and the group development model. When it shows up again two quarters later in IS 330, Database & Data Analysis, for a group project there, they quickly refresh their skills and typically have a smooth-flowing development cycle that lets them focus on building their database skills.
This past term, I began introducing Git and GitHub into lower-level classes, by using it in CIS 225, Advanced C. This course uses Linux with command-line tools (gcc & valgrind), so it was a natural place to introduce git and GitHub.
I kept all class code in a GitHub repository and placed tags with dates - such as jan-05 - so they could pull down the code for a particular class when they viewed its recording.
The class discussion board was put up as a GitHub organization project where students could post cards with questions, and then others could add answers to the cards.
Each assignment was set up as a GitHub Classroom assignment, with a template and starter code. The template typically contained detailed instructions and specifications in the README.md. The skeleton code included and .h and partial .c files to start from. Later projects had just the README.md. Students would get their individual repositories, create a branch, put their code in their branch, and then make a pull request to their master branch to “submit” their completed code.
This worked out nicely. A few students needed additional assistance on using the branch, having missed that step in the instructions, but generally they hit all the steps and gave me a good pull request to review.
I also have the students review each others’ code in the class. This took a bit more effort on my part. I made a “review” repository with an empty master branch and a branch for each student. Then I collected each student’s code from their repository, put it in “their” branch on the review repository, and opened a pull request back to master. This gave the entire class open pull requests to review.
All of this, except the GitHub pull requests, were done with shell scripts to pull down repositories, move between branches, and copy, commit, and push files up to GitHub. (The scripts, however, aren’t shareable – they were thrown together too quickly and are overly brittle and shaped to the particular set of repositories I was working wtih.) I did it this way rather than an original shared repository so that each student wrote their code without access to their peers’ solutions before making their own submissions.
The students enjoyed this sharing of the code, and grasped and used the GitHub review mechanisms very nicely. All saw immediately the value of seeing feedback in context, and were generous with their feedback to their peers. Each student reviewed two of their peers’ submissions, so they saw two other example solutions and drew comparisons to their own work as well.
Earlier sharing of code definitely increased student retention of the material; later assignments saw good ideas applied and bad ideas fixed or avoided. The level of learning was higher than if they had only had my class examples and my feedback on their assignments, i.e. how I have taught the class prior to GitHub.
This class ends with group projects, but unfortunately GitHub Classroom had a meltdown so we were unable to use its capabilities to manage the groups. Instead I set up teams and group repositories for them in the class organization directly, and gave each team access to its repository. I then showed them the development cycle I have used in IS302, and let them loose on their projects.
With this first offering/use, I saw some teams adapt quickly to the development cycle, where others took shortcuts such as having just one person touch the code. There was some resistance to using GitHub from people with prior experience in other tools such as Google Drive or Microsoft Team Foundation Server. However, the shared experience generally brought people to GitHub by the end of the course with an appreciation for its capabilities.
Moving forward from this, I plan to continue integrating GitHub and GitHub Classroom into my classrooms. I’ve been investigating using Morea for course websites; Olympic College uses Canvas as its primary LMS, but permits use of other tools as well. I plan to try out Issues for Q&A type interactions and to continue to use a GitHub repo for class files. And finally, I am looking into introducing forking into the development environment in IS302 to make it more realistically model open-source development models.
I’ve seen other suggestions here of using tools like Travis CI for checking work when it is submitted; this is a great idea for courses like Java, where I already have JUnit tests that help students validate their work. I haven’t explored Travis CI yet beyond basic tutorials, but it seems full of potential and a logical next step.
I did have a previous class use GitHub and AppHarbor to deploy their ASP.NET applications, which was a great experience all the way around - but generally I’ve avoided the use of public repositories and sites due to the nature of the schoolwork; that style of interaction seems appropriate only when each student’s project is unique.
And to make this all swing back around to GitHub Classroom improvements … I’d ask for a way to tie forking in so I could have made pull requests from the student repo’s back to a master repo for group sharing of student code, rather than my method used above; and I’d also ask for private github.io pages publishing, accessible only within the Organization by Organization members, like the repositories.
I hope you’ve enjoyed my story; I’ve learned a lot from the posts of others here, and wanted to share my experiences to help build the collective experience. I’d be happy to answer any questions about what I did, and look forward to continuing to read about others’ experiences.