Private Git repositories for students, that don't become public later

Question

Note: This question was asked before GitHub offered free private repositories.

Short version of my question: Is there a good way to provide students with free, private, Github-like git repositories, that won't become public later?

Background: In computer science, it is considered best practice to use Git (a version control repository) for software development. Many universities want to encourage students to follow those best practices as part of their coursework, so they'd like to encourage students to do the same. However, they don't want student work to be made public, as this creates a temptation for cheating.

Github in particular is popular, as it provides both Git repositories, an easy-to-use web front-end to Git, and a convenient workflow for collaborating using Git. Github is free if you make your repository public; normally, you have to pay for a private repository. Github has a special program for students: as long as you are a student, you can have private repositories for free, if you sign up for their student discount. However, this only lasts as long as you are a student. After two years, the student discount expires, and then the private repositories are locked; if the ex-student wants to retain access to their repositories, the ex-student has 30 days to either pay Github a monthly fee to keep it private, or they can tell Github to make it public and pay nothing.

One university I'm familiar with encourages CS students to sign up for a student Github account and put their projects and homeworks in private repositories. However, empirically, Github's policies seem to encourage a certain number of students to make all their repos public after they graduate and their student status expires -- and then solutions are available on the Internet. Because good software development projects are so labor-intensive to construct, many courses re-use projects for several years in a row. Current students have reported finding this by search and are a bit worried that it'd be so easy for other students to cheat. Therefore, recommending that students use a private Github account seems to create a two-year time bomb that will have unfortunate consequences for courses who plan to use their project for more than two years running.

Is there any good solution to this? Is there a better alternative than Github that can be recommended to students?

In particular, a better alternative should meet the following requirements: allow students to have Git repositories for software development and collaboration with project partners; is free; is private; will remain private over time, without encouraging/requiring alumni to make their solutions public if they want to retain access to their solutions without paying; doesn't create extra work for instructors to constantly search Github to look for inadvertently-public solutions from past semesters.

I've seen How to deal with student putting their (home)work on github, but the solutions there aren't workable in this context: creating new projects every semester is not a good solution (it's been tried and leads to pedagogically inferior results).

Answer 1

Update January 2019: GitHub now has free private repositories.

---

Bitbucket offers unlimited private repositories. I use it for this purpose.

You can also host your students' repositories yourself on your own server with Gitlab (the community edition is free). This option has the advantage that you aren't asking your students to trust a third party with their data. I sometimes use this option, too. It's very easy to set up.

However, having students' work in repositories that don't automatically becomes public doesn't obviate the need to create new projects - students can still opt to post their work publicly. (This is true even if you don't use Git in the course at all.)

Personally, I typically use Bitbucket and ask students to keep their repositories private for the duration of the course (so as not to make cheating too easy), but they are free to make them public later. Part of the appeal of project-intensive courses to students is that they create something they can show off to potential employers. I want my students to have the option to make their work (which is often very impressive, and which they have put a great deal of effort into) public, so that they can enjoy this benefit. I occasionally see students publish their repositories, put a link on their résumés or LinkedIn profiles, and then continue to improve their projects for months after the course is over, which is extremely gratifying.

I would consider it a disservice to students to prevent them from showing off their work after the course is over or after they graduate, even if I could prevent this. My university does not claim ownership of intellectual property produced by students in the context of uncompensated coursework (unless there is an explicit written agreement stating otherwise), so unless their projects also include material which I hold the copyright to, I couldn't stop them from publishing their work even if I wanted to.

Answer 2

There are two other variations you can use with GitHub that are related but independent of the free "Student Pack" features.

Both of these options are free for instructors and are generally preferable to just telling students to get the Student Pack and set their repositories to private.

Either one may work for your needs, but both have some quirks and tradeoffs currently. There are so many subtle details I can't list them all here, plus they are actively developing and changing things. But here's a summary of my experiences:

1. "GitHub Classroom". Last year I tried this option for several assignments one semester. It might work for you, but ultimately I got fed up with the assignments workflow and the fussy "Rosters" it uses. It also prevents students from using the "Fork" feature at all, nor much of any of the other repository admin features. Instead of fork, it has a goofy and error-prone replication feature when they check out an assignment. Another design flaw is that anyone who manages to get the assignment link will be granted access to a copy of the assignment, regardless of whether they're in the roster. Administering teams for groups projects is a pain in this mode too.

2. "GitHub Organization", much better for my situation. Similar to how a company can buy "Organization" configurations from GitHub, these are also available free for educational purposes. It also works even if the student doesn't have the individual "Student Pack" features. So what I've been doing is creating an organization specific to each my course+semester, and requesting GitHub support activate the educational discount. Once that's done (which usually takes less than a day), I can create both public and private repositories within it. I can also create "Teams" with my students in them, to grant them access permissions.

From a professional training perspective, option 2 is much better because the system behaves exactly like they'd encounter in a workplace using GitHub. I typically create a repository for each assignment, containing any baseline files I want them to have, usually set to Private. Then I grant the "team" read access to it. They then create their own fork, which automatically goes in their GitHub account namespace (or potentially in the organization's namespace if you choose to allow that). It will remain private if the upstream is private. Otherwise, they have nearly complete admin features to learn with. Because their homework repositories are forks of mine, it's easy to find all their work, and they can directly grant access to teammates and use any of the fork, branch, merge, etc. features they should be learning. Also, I and my TA automatically retain the ability to access their repositories (read at least), because they forked from the organization.

The only two bugs or design flaws I've had to deal with using GitHub Organizations for coursework are these:

A. The fork of a repository which has team/collaborator permissions automatically COPIES those permissions to the fork, EVEN when the fork is created in the user's namespace. Thus I have to remind them to REMOVE that team as soon as they fork, otherwise the whole class can see their repository contents. I have not found any setting that disables this unwanted inheritance of permissions.

B. You do have to be careful with permissions. For example, if students have already forked a homework repository and you remove the team/collaborators from having read access to the original one, it will instantly and without warning (last time I checked) DELETE all those forks!

Answer 3

It would seem that hosting your own Git server and providing accounts to students is the best alternative. (By "you", I mean your institution, at least the institute or department, if not the university as a whole.)

Going this route allows the university to ensure the repositories will never become public. Any unnecessary trouble of account creation among students could be skipped, as an account could be automatically created for each student (the same way many universities these days automatically create a self-hosted e-mail account for each student).

Lastly, asking students to register with and put their data on any 3rd party website (that might even be abroad and thus subject to different standards of privacy) sounds dubious to me, at the very least for reasons of privacy, but depending on your jurisdiction there may even be legal obstacles to it.

I have written this answer based on my personal experience of working in an institute where an own SVN (back then one of the best practices) was provided to all students. My experience with such a setup were invariably positive.

Answer 4

One option is to create your own "github", check out gitlab. There you can define whatever rules you desire. Downside is that it requires a machine and some manpower to keep it up to date/manage it in general.

Answer 5

A solution one of my professors used was to have herself be the owner of the repo for each team and then just allow each member access.

That way they the students could learn to use Git without having control over whether the repo went public or not; they could write to the repo, but not change its settings.

(There's really no way around the fact that students can still copy files and put them out publicly, somewhere else, however.)