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).

  • 2
    What about running your own GitHub server: stackoverflow.com/questions/8390828/… ?
    – StrongBad
    Commented Apr 19, 2016 at 20:17
  • 2
    I suspect, if you are reusing project, students are more likely to get old solutions from their friends who took the unit last year, than by finding a random solution on github. Therefore, this is a nonissue. Why worry about locking the dog door, when the window is wide open? Commented Apr 20, 2016 at 1:43
  • 1
    @Oxinabox, empirically, we have had cases where people find a random solution on Github (sometimes not even trying to cheat; occasionally deliberately cheating). So while what you're are saying makes a lot of sense... practice doesn't quite seem to bear that out. We have empirical evidence that it isn't a nonissue.
    – D.W.
    Commented Apr 20, 2016 at 1:49
  • 2
    @MassimoOrtolano, obviously, nothing prevents it, except possibly for fond memories of their alma mater and desire for other students to have a chance at the same experience they had. My experience is that ex-students aren't generally going to go publish solutions to past projects after the fact... unless their hosting service provider (e.g., Github) forces them to do so for some reason or another.
    – D.W.
    Commented Apr 20, 2016 at 14:24
  • 2
    For my private repositories, I'm using gitlab... Commented Apr 10, 2018 at 20:28

5 Answers 5


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.

  • 2
    IIRC, bitbucket's free private repos are only for academic users - so I'm not sure what happens when the student's university email address stops working. But agree with the rest of this answer.
    – Flyto
    Commented Apr 20, 2016 at 8:21
  • 4
    @Simon nope. free private repos for any individuals and teams of five or less. (With academic account, you can get > 5.)
    – ff524
    Commented Apr 20, 2016 at 8:23
  • Ah, right! I stand corrected :-)
    – Flyto
    Commented Apr 20, 2016 at 8:24
  • 3
    +1 for the last paragraph. That sentiment should really lead the answer, in my opinion. Students sharing their work (after the course completed of course) is a good thing that should be encouraged, not discouraged.
    – user24098
    Commented Apr 20, 2016 at 10:13

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!


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.


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.


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.)


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .