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.

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:

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 GitHub.com in your GitHub organization. Teams have pretty nifty functionality, including threaded comments and emoji support.

If you create a team for your students on GitHub.com, 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 GitHub.com.

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.

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.

Summary

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.

A new version of Git LFS, the open source Git extension for versioning large files, is now available. Git LFS v2.4.0 comes with a rewrite of the underlying pattern matching engine, an enhanced API, standardized progress meter formatting, bug fixes, and more.

Download Git LFS v2.4.0

A new filepath-filter

With v2.4.0, you’ll get a complete reimplementation of the engine that decides which files do and don’t match commands that accept --include and --exclude flags. That means Git LFS has gained support for character ranges and classes. It’s also a step toward standardizing the meaning of certain patterns—stay tuned for more advanced pattern matching in future LFS releases.

Standardized progress meters

Many of the progress meters that have appeared throughout Git LFS are now unified into a single implementation, which matches Git’s style:

~/example (master) $ git lfs prune
prune: 13 local object(s), 3 retained" prune.log
prune: Deleting objects:  80% (8/10), done" prune.log

The progress meter you see when sending or receiving Git LFS objects is also clearer and more focused. You’ll now see a moving average rate for the transfer—and you’ll no longer see a count of “skipped” objects:

~/Desktop $ git lfs clone git@github.com:ttaylorr/example.git
Cloning into 'example'...
# ...
Downloading LFS objects:  40% (55/136), 96 MB | 15 MB/s

References in the API

Git LFS now includes any affected references in API requests. This change is a first step toward allowing contributions from owners in pull requests using Git LFS.

Additional updates

You’ll also see a handful of other new features and bug fixes in v2.4.0 like git lfs ls-files, new flags in git lfs migrate, more Linux support, and cleaned-up package internals.

And thanks to the great work of the Git LFS open source community, you’ll find support for NTLM SSPI authentication on Windows, fixes for memory alignment issues on 32-bit architectures, and more.

Download Git LFS v2.4.0

You can learn more about v2.4.0 in our release notes—and to see how Git LFS works with GitHub, check out our getting started guide.

For almost two years you’ve been able to use saved replies to quickly respond to multiple issues and pull requests. Now saved replies have keyboard shortcuts to make them even easier to use.

To activate your saved replies press Ctrl . when composing or replying to an issue or pull request. Select the saved reply of your choice with a number, for example Ctrl 2.

Note if your saved reply ends with a # or @ after inserting the saved reply it will attempt to autocomplete an issue or pull request number or username. Check out the documentation to learn more.

Whether you’re a team of one or 100 developers, knowing how people use your GitHub Marketplace app can help you create an even better user experience. Now it’s easier to get insight into your app’s performance with new data views and visualizations. With these new metrics, you can see how many people visited your app’s landing page, track the impact of your marketing campaigns, and more.

Behind the new “Insights” tab on your Marketplace dashboard, you’ll find the data you need to better understand your users and make smarter decisions about your app. You’ll also be able to quickly track performance as you make updates, and offer free trials and promotions.

We can’t wait to see what you do with more data. Take a look at the documentation to find out which insights are available and see how they can move your app forward.

Interested in finding new developer tools? Head to GitHub Marketplace to try out apps that help you track dependencies, deploy software, and manage projects.