Improved pull request merge experience is now generally available

The improved merge experience on the pull request page is now generally available! This update is designed to help you better understand the state of your pull request and get it merged faster.

Screenshot of the updated merge box page on the pull request page showing it is approved, a list of status checks (some failing), and a message about not having any merge conflicts.

This experience supports all the usual ways of merging: direct, bypass and merge, auto-merge, and merge queue, and works with rulesets to ensure pull requests meet all the requirements to merge.

What’s new

The new experience is designed to feel familiar, but also improves on the previous experience. Here are some highlights:

  • Checks grouped by status: checks are now grouped by status with failing checks prioritized at the top of the list, making it easier to identify problems that need attention
  • Checks ordered logically: status checks are now ordered using natural ordering to make it easier to find a specific check, especially when the list gets long
  • Improved rule enforcement: errors resulting from failing commit metadata rules (like invalid commit messages) are now reported at the point of merging so they can be corrected
  • Improved accessibility: consistent keyboard navigation, focus management, and landmarks help make the experience more accessible to everyone

Get help

Learn more about merging a pull request.

To suggest a feature, report a problem, or discuss this improved experience, visit the GitHub Community.

Easily distinguish between direct and transitive dependencies for npm packages

npm’s massive ecosystem of open source packages is one of its greatest strengths. But as a security-conscious developer, it can be tough to keep up with vulnerability reporting and updates once your project has more than a handful of dependencies, each of which has its own set of dependent packages. Dependabot notifies you of vulnerabilities and their fixes as they come in. Unfortunately, it’s hard to distinguish actionable alerts about direct dependencies you’ve added to your manifests from those transitive dependencies that were pulled in along the way… until now, that is.

GitHub’s dependency graph now tracks direct and transitive dependencies for npm packages. This helps you triage, prioritize, and remediate your Dependabot alerts. This capability shows up in user-facing features across the site:

  • Dependabot alerts will now contain a direct label if they are associated with a package you’ve directly included in a manifest. You can filter the list of alerts down to only these direct ones with the relationship:direct filter in the search bar.
  • Alerts for transitive dependencies now show transitive path information – the chain of packages which led from your direct dependency to the transitive one which has the vulnerability.
  • A repository’s dependency graph now distinguishes between direct and transitive relationships. Direct dependencies will have a label in the table UI, whereas indirect dependencies have a disclosure menu that shows the transitive path which led to their inclusion.
  • A repository’s SBOM will contain a relationships section that uses the SPDX relationshipType: DEPENDS_ON field to express the tree of package dependencies. Tools like guac.sh can help explore and visualize this tree.
  • The GraphQL API will now return a relationship field with direct, transitive, or unknown values in the DependencyGraphDependency object. See the API documentation for details.

A table of Dependabot alerts can now be filtered to show only direct dependencies

We started with npm because it’s the most popular package ecosystem in the known universe, but it’s just the beginning. Over the next few months, package types for other programming languages will also get the transitivity treatment. Up next: Maven packages for Java.

To try this out, you’ll need to make sure the dependency graph is enabled. To see the Dependabot labels, you’ll also need to enable Dependabot alerts. If the “Direct” labels aren’t showing up for you immediately, push a commit that updates one of your manifest files, which will trigger an update of the dependency graph.

Join the discussion within GitHub Community.

See more

Introducing metered billing for GitHub Enterprise and GitHub Advanced Security server usage

Scaling your GitHub usage just got easier! We are expanding our pay-as-you-go usage-based billing and licensing reporting interface to include GitHub Enterprise (GHE) and GitHub Advanced Security (GHAS) Server-only usage.

We announced pay-as-you-go billing for GHE and GHAS on August 1, 2024 to give customers flexible self-provisioning and pricing. Since then, enterprise accounts on github.com created on or after that date could generate a GitHub Enterprise Server key for the appropriate license count when license adjustments were needed. This required all users, including Server-only users, to be represented in the enterprise account’s user list on GitHub Enterprise Cloud.

Now, you can track and monitor your Server-only license usage for both Enterprise and Advanced Security as a separate line item on the Billing & Licensing > Licensing page.

Note that it will still be required to add all Server-only users to your GitHub Enterprise Cloud enterprise user list to account for their license usage and generate a license key with the appropriate license count. This update does not change this compliance requirement.

Enterprise Server summary in licensing

For existing customers who already have GHE or GHAS, your plan and existing billing method will remain as-is.

If you are interested in pay-as-you-go usage-based billing and have a GitHub account team, please connect with them to discuss whether switching to this model is an option for you.

Check out our documentation to learn more about usage-based billing for licenses.

See more
View all changes