Over the last month, we’ve introduced some improvements to help you build with the GitHub platform. From listing an app on our Marketplace more quickly, to improvements to our GraphQL API, it’s never been easier to build apps that work seamlessly with GitHub.
Integrators now have the ability to get started with GitHub Marketplace themselves—which means less time waiting in a queue and faster onboarding. This Getting Started guide explains everything you need to know to get setup on GitHub Marketplace, from marketing guidelines to API endpoints and catching webhooks.
We added new objects and mutations to our GraphQL API that allow you to read and manage team discussions. Team discussions is the first GraphQL feature to use a preview period—the same process we’ve used for our REST API in the past. As always, if you want to find out about upcoming GraphQL schema changes, follow the GraphQL Changelog, which now includes preview periods, too.
We’ve added a new page to our documentation that allows you to see what GraphQL schema members are expected to change before they change. It’s sorted in date-descending order so you can see which changes will happen soonest. We strive to minimize breaking changes. When we do have to make them, we want to ensure that you have ample time to update your integration.
Learn more about how to build an app of your own, or find an app that will level up your workflows.
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.
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.
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
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
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.
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.
Download GitHub Enterprise 2.13
To learn more, check out our release notes or RSVP for one of our upcoming webcasts:
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.
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 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.
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.
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.