Back to GitHub Support Contact GitHub

The most popular courses on GitHub

Thousands of teachers use GitHub to host their courses, distribute assignments, and get insight into student progress. Many teachers open source their materials, so other teachers can use them. Between Massive Open Online Courses (MOOCs) and custom lessons from individual teachers, there’s plenty of materials for new teachers to adapt and reuse in their classrooms.

After seeing the growth of educational repositories on GitHub, we put together a list of some of the most popular courses. Courses were selected based on forks (repository copies) and stars (bookmarks that indicate interest). You’ll also find documentation for each of the repositories to guide you through the course materials.

If we missed a course, or if you’d like yours included in a more extensive list, let us know in the GitHub Education Community.

Top courses based on stars

1. Ada Developers Academy’s Jump Start Curriculum (223 stars)

ADA’s Jump Start Curriculum helps prospective students become familiar with the tools, concepts, and vocabulary they’ll need to be successful in the larger program. Each lesson begins with stating learning goals, so students can be sure they’re retaining what they need to prior to entering the program.

2. React From Zero (207 stars)

React From Zero is a straightforward introduction to React that is broken into 17 parts. Each part of the tutorial is in the code for that lesson, using comments to explain concepts in React and examples right in the editor. Each lesson also links to a preview of how the code renders in a browser, so you can follow along and immediately see the outcome of code while you’re learning.

3. Hear Me Code’s Python Lessons (199 stars)

Hear Me Code, based in Washington, D.C., is an organization that offers free, beginner-friendly classes to women. This repository has a “Start Here” guide for those who’ve never installed or run Python before. The lessons are broken into 16 sections, each covering a different concept. Hear Me Code’s slides are also hosted on GitHub, so it’s easy for you to follow this curriculum on your own.

4. Ada Developers Academy’s Textbook Curriculum (154 stars)

Ada Developers Academy is a tuition-free program for women and gender-diverse people to learn software development. Their first repository on this list is their textbook curriculum, which anyone can use. It touches on everything from Git and agile workflows to Ruby, Rails, databases, JavaScript, and Backbone.js.

5. Prep Course for North American University’s Chapter of Association for Computing Machinery International Collegiate Programming Competition (82 stars)

This repository is an 11-week prep course for programming competitions, but it can be used to practice algorithm challenges for interviews or improve algorithmic thinking. Prior programming knowledge and familiarity with data structures will help students who want to get started with this advanced course.

Top courses based on forks

1. Stanford TensorFlow Tutorials (2,452 forks)

These tutorials go along with Stanford’s TensorFlow for Deep Learning Research course. The syllabus, slides, and lecture notes are all available on the website, and each week’s assignments and examples are available in this repository.

2. Deep Learning Specialization on Coursera (1,133 forks)

This student-created repository includes all work from Coursera’s Deep Learning Specialization programming assignments. While this repository itself is not a curriculum, it’s a helpful guide for self-teaching and reading more about the concepts and solutions from this deep learning series of courses.

3. Creative Applications of Deep Learning with Tensorflow (591 forks)

This repository is comprised of assignments and lecture transcripts for Kadenze Academy’s Creative Applications of Deep Learning with TensorFlow curriculum. There are a total of five courses, and the repository also contains extensive documentation on setup and getting started with the tools students will need.

4. Practical RL: A course in reinforcement learning in the wild (401 forks)

This course is taught on-campus in Russian at the Higher School of Economics, but its online version is available to both English and Russian speakers. The entire course is nine weeks long, and the repository also contains bonus materials for students to explore after completing the curriculum.

5. Data Science Coursera (152 forks)

Michael Galarnyk, a Data Science M.A. student, decided to document his journey through Johns Hopkins’ Coursera Data Science curriculum as a supplement to his program at UC San Diego. Along with a directory for each course and its assignments, there’s also a link to a blog post reviewing each course week-by-week, so prospective students can get an idea of what to expect each week.

Find more course materials in the Education Community

For teachers who want to explore more courses, we posted a more extensive list in the GitHub Education Community. You’ll find tips, tricks, and scripts from teachers around the world who are passionate about computer science education.

Go to the Education Community site

Removing support for anonymous gist creation

As mentioned in our deprecation notice post, we’ve deprecated anonymous gist creation as of today, March 20.

All existing anonymous gists will always remain accessible, and it’s easy to create a GitHub account to make the most of a new gist. Check out the documentation to learn more.

Save the date: GitHub Universe 2018

GitHub Universe 2018, October 16-17

GitHub Universe, our flagship product and community conference, is returning this year to a new location. Join us October 16-17 at the Palace of Fine Arts for more sessions, more demonstrations, and more chances to meet with the best developer community in the known universe. Secure your spot with an early bird ticket or submit a speaker proposal if you’d like to lead a session.

Pick up an early bird ticket

Early bird tickets are available now for $99. Super early bird pricing will be available until April 20, but don’t wait—tickets will sell out.

Get early bird tickets

Submit a speaker proposal

Want to share your story at Universe? We’re calling for speakers to share ideas about the tools, people, and businesses behind software during Universe breakout sessions.

Submit a proposal

EU wants to require platforms to filter uploaded content (including code)

$ git push 
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
remote: error: GH013: Your push could infringe someone's copyright.
remote: If you believe this is a false positive (e.g., it's yours, open
remote: source, not copyrightable, subject to exceptions) contact us:
remote: We're sorry for interrupting your work, but automated copyright
remote: filters are mandated by the EU's Article 13.
 ! [remote rejected] patch-1 -> patch-1 (push declined due to article 13 filters)

The EU is considering a copyright proposal that would require code-sharing platforms to monitor all content that users upload for potential copyright infringement (see the EU Commission’s proposed Article 13 of the Copyright Directive). The proposal is aimed at music and videos on streaming platforms, based on a theory of a “value gap” between the profits those platforms make from uploaded works and what copyright holders of some uploaded works receive. However, the way it’s written captures many other types of content, including code.

We’d like to make sure developers in the EU who understand that automated filtering of code would make software less reliable and more expensive—and can explain this to EU policymakers—participate in the conversation.

Why you should care about upload filters

Upload filters (“censorship machines”) are one of the most controversial elements of the copyright proposal, raising a number of concerns, including:

  • Privacy: Upload filters are a form of surveillance, effectively a “general monitoring obligation” prohibited by EU law
  • Free speech: Requiring platforms to monitor content contradicts intermediary liability protections in EU law and creates incentives to remove content
  • Ineffectiveness: Content detection tools are flawed (generate false positives, don’t fit all kinds of content) and overly burdensome, especially for small and medium-sized businesses that might not be able to afford them or the resulting litigation

Upload filters are especially concerning for software developers given that:

  • Software developers create copyrightable works—their code—and those who choose an open source license want to allow that code to be shared
  • False positives (and negatives) are especially likely for software code because code often has many contributors and layers, often with different licensing for different components
  • Requiring code-hosting platforms to scan and automatically remove content could drastically impact software developers when their dependencies are removed due to false positives

The EU Parliament continues to introduce new proposals for Article 13 but these issues remain. MEP Julia Reda explains further in a recent proposal from Parliament.

EU policymakers want and need to hear from developers

As part of our ongoing collaboration with others affected, GitHub will help represent developers at an upcoming breakfast in Parliament on Tuesday, March 20, intended to show the human impact of this copyright proposal.

EU policymakers have told us it would be very useful to hear directly from more developers. In particular, developers at European companies can make a significant impact.

How to reach EU policymakers

  1. Write to EU policymakers (MEPs, Council Members, or Commissioners) and ask them to exclude “software repositories” from Article 13. Please explain how important the ability to freely share code is for software developers and how important open source software is to the software industry and the EU economy

  2. Explain this :point_up: in person to EU policymakers

GitHub can help connect you with policymakers, provide additional background, or chat if you might be interested in representing software developers in defending your ability to share code and not have your builds break. Get in touch!

Four years of the GitHub Security Bug Bounty

Last month GitHub celebrated the fourth year of our Security Bug Bounty program. As we’ve done in the past, we’re sharing some details and highlights from 2017 and looking ahead to where we see the program going in 2018.

2017 in review

Last year was our biggest year yet as our Bug Bounty program continued to grow in participation by researchers, program initiatives, and the rewards paid out.

Diving straight into the numbers, we can review the details of this growth. In 2017, we reviewed and triaged a total of 840 submissions to the program. Of these submissions, we resolved and rewarded a total of 121 reports with an average payout of $1,376 (and swag!). Compared to our previous statistics for 2016, this was a significant increase from 48 out of 795 reports being resolved. In 2017, our rate of valid reports increased from 6% to almost 15%.

Our total payouts also saw a significant increase from $95,300 in 2016 to $166,495 in 2017. We attribute this to the increased number of valid reports and in October we took time to re-evaluate our payout structure. Corresponding with HackerOne’s Hack the World competition, we doubled our payout amounts across the board, bringing our minimum and maximum payouts to $555 and $20,000, bringing our bug bounty in line with the industry’s top programs.

2017 initiatives

To accelerate our program’s growth in 2017, we launched a number of initiatives to help engage researchers. Among the changes to the program was the introduction of GitHub Enterprise to the scope of the Bug Bounty program, which allowed researchers to focus on areas of our applications that may not be exposed on or are specific to certain enterprise deployments. In the beginning of 2017, a number of reports impacting our enterprise authentication methods prompted us to not only focus on this internally, but also identify how we could engage researchers to focus on this functionality. To promote a more targeted review of these critical code paths we kicked off two new initiatives beyond our public Bug Bounty program.

Researcher grants

Providing researcher grants is something that has been on our radar since Google launched their Vulnerability Research Grants in 2015. The basic premise is that we pay a fixed amount to a researcher to dig into a specific feature or area of the application. In addition to the fixed payment for the grant, any vulnerabilities identified would also be paid out through the Bug Bounty program. During the beginning of the year, we identified a researcher with specialty in assessing troublesome enterprise authentication methods. We reached out and launched our first researcher grant. We couldn’t have been happier with the results. It provided a depth of expertise and review that was well worth the extra monetary incentive.

Private bug bounty

In March 2017 we launched GitHub for Business, bringing enterprise authentication to organizations on We used this feature launch as an opportunity to roll out a new part of the Bug Bounty program: private bug bounties. Through a private program on HackerOne, we reached out to all researchers who had previously participated in our program and allowed them access to this functionality before its public launch. This added to our internal pre-ship security assessments with review by external researchers and helped us identify and remediate issues before general exposure. With the extra review, we were able to limit the impact of vulnerabilities in production while also providing fresh code and functionality for researchers to look into.

Operational efficiency

Internal improvements to the program have helped us more efficiently triage and remediate submissions from researchers. ChatOps and GitHub-based workflows are core to how we deal with incoming submissions. As soon as new ones arrive, we receive alerts in Slack using HackerOne’s Slack integration. From there, we can triage issues directly from chat, letting the team know which issues are critical and which can wait until later. At the end of our triage workflow, we use ChatOps to issue rewards through HackerOne, so we can close the loop and pay researchers as quickly as possible.

To support these workflows, we’ve continued to build on our Ruby on Rails HackerOne API client and extensively use these and GitHub APIs in our internal processes.

So far, these improvements have made us significantly more efficient. Our average response time in 2017 was 10 hours, valid issues were triaged to developers on average within two days, and bounties were rewarded on average in 17 days. Given the time and effort that researchers dedicate to participating in our program, we feel great about these improvements. And in 2018, we’ll continue to refine our process. We’re always looking for ways to make sure our researchers receive a prompt and satisfactory response to their submissions.

What’s next?

Also in 2018, we’re planning to expand the initiatives that proved so successful last year. We’ll be launching more private bounties and research grants to gain focus on specific features both before and after they publicly launch. Later in the year, we’ll announce additional promotions to continue to keep researchers interested and excited to participate.

Given the program’s success, we’re also looking to see how we can expand its scope to help secure our production services and protect GitHub’s ecosystem. We’re excited for what’s next and look forward to triaging and fixing your submissions this year!


Discover new ways to build better

Try Marketplace apps free for 14 days

Learn more