Back to GitHub Support Contact GitHub

Patchwork Orlando

Patchwork is headed to Orlando! This event is open to beginners to Git and GitHub and mentors who want to help others learn. We’ll have stickers for everyone, and a little something extra for the mentors, so we hope to see you there.

Canvs Orlando

Special thanks to our partners for the event:

GitHubbers and community mentors will be on hand to walk the attendees through their choice of learning modules:

  • GitHub 101: Introduction to GitHub
  • GitHub 102: Using the GitHub Desktop
  • GitHub 103: Using the Command Line

No coding experience needed

Patchwork is a self-directed, hands-on workshop for learning Git and GitHub. The atmosphere is casual and informal—it’s not an event full of presented tutorials and copious note-taking. You will be able to go at your own pace with the help of a community mentor nearby in case you run into any trouble. Join us for a night of hacking and snacking and make some new friends while you’re at it!

Newcomers to Git and GitHub: you’ll leave with a merged pull request, a square on your contributions graph, and the confidence to get more involved in the open source community.

Mentors: if you’ve ever had a pull request merged, now is your chance to share the love and help someone else create magic. :sparkles:


For: Beginners to Git and GitHub
When? April 11, 2018 6:30-9:30 pm
Where? Canvs: Downtown Orlando, 101 S. Garland Avenue, Suite #108, Orlando, FL 32801 (This venue is wheelchair friendly, and provides gender-neutral restrooms)

If you do not yet have a GitHub account, we ask that you sign up at before you attend the event. It’s fast, easy, and of course, free. This way you’ll be ready to go right out of the gate.

We will provide food and refreshments. If you have any food allergies, please let us know during registration.

The International Conference on Game Jams, Hackathons, and Game Creation Events: Sunday March 18, 2018

International Conference on Game Jams, Hackathons, and Game Creation Events Logo

You’re invited to the third annual International Conference on Game Jams, Hackathons, and Game Creation Events (ICGJ), happening Sunday, March 18, at GitHub HQ in San Francisco.

Organized by Global Game Jam, ICGJ is an interdisciplinary conference for educators, researchers, professionals, and event organizers who organize or participate in game jams and hackathons. Check out the ICGJ website for the complete schedule of papers, presentations, lightning talks, and games being showcased at the event.

Register now

Date: Sunday March 18, 2018
Time: 9 am - 6:30 pm PST
Address: 88 Colin P Kelly Jr St, San Francisco, CA 94107

Release Radar · February 2018

February 2018 Release Radar

February is the shortest month, but that doesn’t mean it’s short on new releases. From games to web apps, here are some projects that caught our attention with big releases last month.

Asciinema 2.0

Fancy yourself a director of terminal demos? Record your next terminal session with Asciinema. It’s a delightful open source tool that records terminal sessions as characters, not video. When you play back your session on, you see text (not images) that your audience can copy and paste into their own terminals.

Recording and listing terminal activity with the latest release of asciinema

Asciinema 2.0 introduces the new asciicast v2 file format, which has reduced Asciinema’s memory use, increased the maximum length of a recording, and powers terminal-to-terminal streaming. What’s more, in-progress recordings won’t be lost if your terminal session is interrupted because the new format will let you pick up from where you left off. This calls for a party parrot.

Did you know? The new asciicast format uses the JSON Lines text format, also known as a newline-delimited JSON file, for incremental reads and writes.

Phaser 3

Phaser 3 logo

Phaser is “a fast, free, and fun open source” framework that helps you make games with HTML and Javascript. It supports both desktop and mobile browsers, plus third party tools can even compile games as native apps iOS and Android. The latest release, Phaser 3, is a huge achievement that follows one-and-a-half years of development. The release is a major rewrite of the framework’s internals, including its renderer and state management. The latest edition of Phaser World has all of the details.

There’s no doubt that this release will lead to some exciting new games. Whether it’s from learning to code with a robot pirate to riffs on old school classics, the Phaser community is a fount of creativity. Feeling inspired? Check out the guide to making your first Phaser 3 game.

Did you know? The Minecraft Hour of Code Tutorials, enjoyed by tens of millions of kids around the world, were built with Phaser.

Webpack 4.0.0

webpack is a static module bundler. That means it takes in your application’s dependencies and turns them into a tidy, browser-friendly unit, but that’s underselling it. With a host of available plugins, webpack can transform code, images, styles, and more into static assets.

webpack 4’s banner feature is speed. There are reports of build times decreasing by 60 to 90 percent! Version 4 also introduces new defaults for development and production modes, entry points, and outputs, so you can get started without any configuration. There’s heaps more changes, too, which you can read all about in the webpack 4 release announcement.

Did you know? Webpack 4 is codenamed “Legato”, an Italian word for “tied” and a musical term which means to play notes smoothly connected. Are those speed increases music to your ears, too?

Next.js 5

Next.js is a toolkit that helps you make server-rendered React applications. The latest release, Next.js 5, has been refactored to support webpack’s features for both client bundles and server code. On top of that, Next.js has added support for TypeScript and webpack’s CSS loaders, strengthening the toolkit’s ability to reuse existing codebases. Check out the Next.js 5 announcement because it’s an impressive release!

Did you know? You can learn Next.js at the appropriately-named

HaxePunk 4.0

HaxePunk helps you make games for any platform: desktop (Windows, Mac, and Linux), web, and mobile (iOS and Android). HaxePunk 4.0 has been in development for over a year and that hard work has paid off. This release introduces custom shaders, signals for hooking into various events, and a improved system for getting device input. Check out the HaxePunk 4.0 release announcement for more details.

Did you know? HaxePunk is a port of FlashPunk to the Haxe programming language.

That’s just a handful of releases you shipped last month—keep them coming! If you’ve got a release that should be on our radar, send us a note.

How to use group assignments in GitHub Classroom

Like professional developers working together on code, students can use GitHub Classroom to collaborate on group projects in a shared repository. In this post, we’ll walk you through how teachers can work with GitHub teams and use GitHub Classroom to create group exercises, assign teams, and reuse existing student teams.

Before you begin

Before you create a group exercise, you’ll need the following:

  • A GitHub organization with a discount for private repositories and access to GitHub Classroom

  • An exercise (a repository that you have access to, which contains documentation, starter code, tests, or anything else your students need to begin work on an assignment)

  • A list of students, or unique identifiers like their email addresses

Get started

To get started, log in to GitHub Classroom, choose one of your classrooms, then click the New assignment button followed by Create group assignment. This brings you to the “New group assignment” page where you can provide the details of an assignment. If you don’t see your classroom listed, double check that you’ve granted that organization access to GitHub Classroom.

a mouse cursor clicks on a GitHub Classroom classroom, then clicks the "New assignment button", then clicks the “Create group assignment” button, text begins to appear in the first text field. The animation loops from the beginning

Then set up your group assignment just like you’d setup an individual assignment. Pick a name for your exercise, a starter repository to share, and a deadline.

Create and use groups

When creating a new exercise, you can choose whether to reuse a set of groups from a previous assignment or name a set of new groups. If you’re reusing existing groups, then select a set of teams from the “Choose an existing set of groups” drop-down list.

If your students are going to form a new set of teams, enter a name for the set of teams in the “Create a new set of teams” field. It’s helpful to name your set of teams after their intended duration. For example, if you want to use a set of teams for one assignment, name it after that assignment. If you’d like to reuse a set of teams for a whole semester, name it after the semester or course.

When you’ve completed the form, click the “Create Assignment” button. Now it’s time to invite your students to the assignment.

Form student groups

On the assignment page, you’ll find a unique invitation link. Share this link with your students through your learning management system, course homepage, or however you distribute assignments. Keep in mind that anyone with the link can use it, so be careful where you share it.

If you’re using a new set of groups for this exercise, and you’d like to assign students to specific group, give your students a list of people who should join each group, along with the group’s name.

Once your students have clicked the link, they may be asked to join a group (if you’re not reusing an existing set of groups). It looks like this:

a mouse cursor clicks on an invite link for an assignment, a list of GitHub Classroom groups appears, the cursor clicks on the "Create a new groups" field, "Team 2" is entered into the text field, the cursor clicks the “Create groups” button, and the “You are ready to go!” page appears. The animation loops from the beginning

There are three common cases when organizing students into teams:

  • There are no groups yet. The student will have to enter the name of a new group to create it
  • There are one or more groups already formed. The student clicks on the existing group they want to join
  • A student needs to create a new group. The student enters the name of a new group to create it

Classroom groups and GitHub teams

When students join their group in Classroom, a team is created on in your GitHub organization. Teams have pretty nifty functionality, including threaded comments and emoji support.

If you create a team for your students on, that team will not appear in Classroom. If you’d like to use Classroom to distribute shared repositories, then use group assignments in Classroom, not teams on

When you use group assignments in Classroom, each team of students will get access to one shared repository for the exercise. Every student will be able to push and pull to their team’s repository. We recommend assigning one student per team to act as project manager to resolve conflicts or merge pull requests. If your students are new to resolving conflicting changes, they can check out our documentation to learn to manage merge conflicts.

Get deeper insight into group participation

Once your students are sorted into teams, they can start collaborating on the assignment like they would in any other repository: by pushing commits and branches, opening and reviewing pull requests, or using issues. Similarly, all of their commit history is available for you to review.

As students finish up their assignments, you can see the work they’ve done in two ways. Examine the current state of the files to see the finished product or look through the repository’s history to see how students worked together. GitHub’s “Insights” tab provides you with a picture of how your students worked together. For example, “Pulse” data gives you a timeline of your students’ pull requests, issues, and conversations, while “Contributors” graphs visualize your students’ additions and deletions.

Once students complete their projects, there are a few ways to deliver feedback, including:

  • Going to the list of commits and making comments on individual commits
  • Weighing in on a per-line basis (if students used pull requests)
  • If you find that students make a similar error over and over, creating a canned reply and opening an issue directly from the plus sign (“+”) in the code view

If you chose to use private repositories for your assignment, your feedback will be confidential, so only you and the students in the group will see it.

Create a group exercise

Ready to give a group assignment? Get started right away in GitHub Classroom. Or check out this discussion in the GitHub Education Community on how student groups can work with GitHub teams in Classroom.

Measuring the many sizes of a Git repository

Is your Git repository bursting at the seams? git-sizer is a new open source tool that can tell you when your repo is getting too big. git-sizer computes various Git repository size metrics and alerts you to any that might cause problems or inconvenience.

What is “big”?

When people talk about the size of a Git repository, they often talk about the total size needed by Git to store the project’s history in its internal, highly-compressed format—basically, the amount of disk space used by the .git directory. This number is easy to measure. It’s also useful, because it indicates how long it takes to clone the repository and how much disk space it will use.

At GitHub we host over 78 million Git repositories, so we’ve seen it all. What we find is that many of the repositories that tax our servers the most are not unusually big. The most challenging repositories to host are often those that have an unusual internal layout that Git is not optimized for.

Many properties aside from overall size can make a Git repository unwieldy. For example:

  • It could contain an astronomical number of Git objects (which are used to store the repository’s history)

  • The total size of the Git objects could be huge when uncompressed (even though their size is reasonable when compressed)

  • When the repository is checked out, the size of the working copy might be gigantic

  • The repository could have an unreasonable number of commits in its history

  • It could include enormous individual files or directories

  • It could contain large files/directories that have been modified very many times

  • It could contain too many references (branches, tags, etc)

Any of these properties, if taken to an extreme, can cause certain Git operations to perform poorly. And surprisingly, a repository can be grossly oversized in almost any of these ways without using a worrying amount of disk space.

It also makes sense to consider whether the size of your repository is commensurate with the type and scope of your project. The Linux kernel has been developed over 25 years by thousands of contributors, so it is not at all alarming that it has grown to 1.5 GB. But if your weekend class assignment is already 1.5 GB, that’s probably a strong hint that you could be using Git more effectively!

Sizing up your repository

You can use git-sizer to measure many size-related properties of your repository, including all of those listed above. To do so, you’ll need a local clone of the repository and a copy of the Git command-line client installed and in your execution PATH. Then:

  1. Install git-sizer
  2. Change to the directory containing your repository
  3. Run git-sizer. You can learn about its command-line options by running git-sizer --help, but no options are required

git-sizer will gather statistics about all of the references and reachable Git objects in your repository and output a report. For example, here is the verbose output for the Linux kernel repository:

$ git-sizer --verbose
Processing blobs: 1652370
Processing trees: 3396199
Processing commits: 722647
Matching commits to trees: 722647
Processing annotated tags: 534
Processing references: 539
| Name                         | Value     | Level of concern               |
| ---------------------------- | --------- | ------------------------------ |
| Overall repository size      |           |                                |
| * Commits                    |           |                                |
|   * Count                    |   723 k   | *                              |
|   * Total size               |   525 MiB | **                             |
| * Trees                      |           |                                |
|   * Count                    |  3.40 M   | **                             |
|   * Total size               |  9.00 GiB | ****                           |
|   * Total tree entries       |   264 M   | *****                          |
| * Blobs                      |           |                                |
|   * Count                    |  1.65 M   | *                              |
|   * Total size               |  55.8 GiB | *****                          |
| * Annotated tags             |           |                                |
|   * Count                    |   534     |                                |
| * References                 |           |                                |
|   * Count                    |   539     |                                |
|                              |           |                                |
| Biggest objects              |           |                                |
| * Commits                    |           |                                |
|   * Maximum size         [1] |  72.7 KiB | *                              |
|   * Maximum parents      [2] |    66     | ******                         |
| * Trees                      |           |                                |
|   * Maximum entries      [3] |  1.68 k   |                                |
| * Blobs                      |           |                                |
|   * Maximum size         [4] |  13.5 MiB | *                              |
|                              |           |                                |
| History structure            |           |                                |
| * Maximum history depth      |   136 k   |                                |
| * Maximum tag depth      [5] |     1     | *                              |
|                              |           |                                |
| Biggest checkouts            |           |                                |
| * Number of directories  [6] |  4.38 k   | **                             |
| * Maximum path depth     [7] |    14     | *                              |
| * Maximum path length    [8] |   134 B   | *                              |
| * Number of files        [9] |  62.3 k   | *                              |
| * Total size of files    [9] |   747 MiB |                                |
| * Number of symlinks    [10] |    40     |                                |
| * Number of submodules       |     0     |                                |

[1]  91cc53b0c78596a73fa708cceb7313e7168bb146
[2]  2cde51fbd0f310c8a2c5f977e665c0ac3945b46d
[3]  4f86eed5893207aca2c2da86b35b38f2e1ec1fc8 (refs/heads/master:arch/arm/boot/dts)
[4]  a02b6794337286bc12c907c33d5d75537c240bd0 (refs/heads/master:drivers/gpu/drm/amd/include/asic_reg/vega10/NBIO/nbio_6_1_sh_mask.h)
[5]  5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c (refs/tags/v2.6.11)
[6]  1459754b9d9acc2ffac8525bed6691e15913c6e2 (589b754df3f37ca0a1f96fccde7f91c59266f38a^{tree})
[7]  78a269635e76ed927e17d7883f2d90313570fdbc (dae09011115133666e47c35673c0564b0a702db7^{tree})
[8]  ce5f2e31d3bdc1186041fdfd27a5ac96e728f2c5 (refs/heads/master^{tree})
[9]  532bdadc08402b7a72a4b45a2e02e5c710b7d626 (e9ef1fe312b533592e39cddc1327463c30b0ed8d^{tree})
[10] f29a5ea76884ac37e1197bef1941f62fda3f7b99 (f5308d1b83eba20e69df5e0926ba7257c8dd9074^{tree})

The git-sizer project page explains the output in detail. The most interesting thing to look at is the “level of concern” column, which gives a rough indication of which parameters are high compared with a typical, modest-sized Git repository. A lot of asterisks would suggest that your repository is stretching Git beyond its sweet spot, and that some Git operations might be noticeably slower than usual. If you see exclamation marks instead of asterisks in this column, then you likely have a problem that needs addressing.

As you can see from the output, even though the Linux kernel is a big project by most standards, it is fairly well-balanced and none of its parameters have extreme values. Some Git operations will certainly take longer than they would in a small repository, but not unreasonably, and not out of proportion to the scope of the project. The kernel project is comfortably manageable in Git.

If the git-sizer analysis flags up any problems in your repository, we suggest referring again to the git-sizer project page, where you will find many suggestions and resources for improving the structure of your Git repository. Please note that by far the easiest time to improve your repository structure is when you are just beginning to use Git, for example when migrating a repository from another version control system, before a lot of developers have started cloning and contributing to the repository. And keep in mind that repositories only grow over time, so it is preferable to establish good practices early.


Git is famous for its speed and ability to deal with even quite large development projects. But every system has its limits, and if you push its limits too hard, your experience might suffer. git-sizer can help you evaluate whether your Git repository will live happily within Git, or whether it would be advisable to slim it down to make your Git experience as delightful as it can be.

Getting involved: git-sizer is open source! If you’d like to report bugs or contribute new features, head over to the project page.


Discover new ways to build better

Try Marketplace apps free for 14 days

Learn more