Our latest changes to organization project permissions introduce more possibilities for your organization’s workflow. Collaborate with your team in new ways, expand who you work with, and, if you’d like, publicly communicate your progress across projects to the community.

More granular permissions for organization projects

Sometimes projects aren’t relevant to every organization member. Now you can set permissions for your organization’s projects that specify which members can see or edit a project.

We’re also expanding the ways you can collaborate with others, so you can invite outside collaborators to your projects, too. Bring in external team members like contractors to work with you on certain projects without having to add them directly to your organization—the same way that repository permissions work.

Happy with your permissions the way they are? Permissions for existing project won’t change unless you update their collaboration settings or create a new project using the new permissions options.

Public organization projects

Previously, you had to create a repository-level project on a public repository to share a project with the world. Now you can create public projects at the organization level, too. Share your organization’s public roadmap with the world, or set up a project to triage incoming issues that span multiple repositories for a single open source project. We’re excited to see how you use public projects to tell the world what you’re working on.

For more detailed information on how to work with organization project permissions, see the documentation.

Our latest GitHub Enterprise release has arrived with new ways for teams to collaborate, manage permissions, build custom tools, and more. Here’s an overview of what you’ll get when you upgrade to 2.13.

Download GitHub Enterprise 2.13

More collaboration

Team discussions

Team discussions give your team a dedicated home for conversations that aren’t related to code changes—so they’re easy to find when you need them without cluttering issues and pull requests.

Learn more about team discussions

Commit co-authors

With commit co-authors, your team can see who has contributed to every commit, regardless of how many contributors there are and make sure every author gets attribution in the pull request and in their contribution graph.

Learn more about commit co-authors

Seamless admin

Built-in authentication with external providers

It’s easier than ever to make sure the right developers, contractors, and machine users have access to your instance with built-in authentication providers. And having more than one authentication process means that you always have a fallback when an external adaptor goes down or is undergoing maintenance.

Extended pre-receive hooks

We’ve extended pre-receive hooks so policies can be configured when code is pushed to your instance. With Git push options (--push-options), developers can transmit strings to the server for your pre-receive hooks.

Hotpatching for clustering

With hotpatching updates, you’ll now be able to roll out hotpatches for clustering without downtime.

Grafana in your Monitor Dashboard

Your Monitor Dashboard just got an upgrade of its own with the help of Grafana! Now you’ll be able to access more detailed performance graphs for your instance and have more control over how you analyze and share data in your organization.

Custom tools

GitHub Apps

GitHub Apps are fresh out of preview and fully available for teams using GitHub Enterprise 2.13. Now you can customize your workflow in just about any way you’d like with the help of GitHub APIs.

Learn more about GitHub Apps

Download GitHub Enterprise 2.13

To learn more, check out our release notes or RSVP for one of our upcoming webcasts:

• What’s new in GitHub Enterprise (Americas)
• What’s new in GitHub Enterprise (EMEA)
• What’s new in GitHub Enterprise (APAC)
• What’s new in GitHub Enterprise (Japanese)

Sadly, GDC 2018 is coming to a close. Tens of thousands of developers visited San Francisco to explore the latest and greatest in the gaming industry—including a large number of Unity developers who might be excited to hear that we’ve released GitHub for Unity Beta to support them through their adventures in game development.

GitHub for Unity Package

Our Unity package provides Unity game developers with the benefits of source control and GitHub without having to switch to the command line. The package already included basic Git support from within Unity and allowed you to use GitHub features in just a few clicks. With our latest update, you can now take advantage of Git LFS and file locking, too.

Git-LFS and file locking

Git-LFS provides a unique experience for game developers. With the ability to store your large asset files outside your repository (but still on GitHub.com servers) your repository becomes a more manageable size, making cloning and fetching much faster. You gain versioning and the same integrated Git workflow you use for text files for large asset files. Git-LFS also brings your team file locking, ensuring your assets are not overwritten or corrupted.

All of our features

• Unity 5.4 and above on both Mac and Windows
• GitHub authentication (including 2fa) with HTTPS support
• Git management added to Unity, providing users with user and email configuration, Git remote configuration, and Git installation path configuration
• Local repository management including a list of changes, selective commit, and the ability to discard file changes
• Git and GitHub repository operations including lists of commits with details that can be reverted and branch operations including listing local and remote branches. You can also create and publish new branches, delete existing branches, and of course fetch, push, and pull operations between local and remote
• File locking with visual locking indicators in the UI within the file, a list of locked files, and notifications when a file is locked by someone else

Open source

And don’t forget, our package is open source. We encourage you to share feedback, report bugs, and contribute where you can! Just visit our GitHub for Unity repository to get started!

As your projects grow in size and complexity, it can be challenging to make sure all of the code changes are reviewed by enough people on your team. Now, with the a multiple reviewer requirement, you can specify exactly how many people are required to review every pull request—so important projects are protected from unwanted changes. 

How it works

To require multiple reviewers for pull requests, go to your repository’s settings and select “Branches”. Under “Protected branches”, select the branch you’d like to protect with a multiple reviewers requirement. There you can select the number of reviewers required for each pull request to that branch.

After you’ve selected the number of reviewers, you’ll see that number and the status of their reviews in the sidebar and merge section of pull requests to protected branches.

Learn more about required reviews for pull requests

Whether you’re working on open source projects or collaborating with new developers on your team, it’s not always clear who you’re working with and how they’re connected to the project you’re working on.

With hovercards, you can hover your mouse over a contributor’s avatar—or most places you see their username—to get more information about who you’re collaborating with. On every hovercard, you’ll see a larger avatar image and profile information, so be sure to check if your profile is up to date with what you want others to see on your hovercard.

You’ll also see information about the individual that’s specific to your interaction with them, like which teams they belong to in your organization, if they are a code owner, if they’re contributing to their very first pull request, and more.

REST API and GraphQL API support are currently in preview—and stay tuned for hovercards in a GitHub Enterprise release soon.

Learn more about the hovercard REST API

Learn more about the hovercard GraphQL API