Are you using our GitHub app in Microsoft Teams or Slack? Do you find it difficult to track all the notifications you get in your channels?
If yes, here comes a feature that helps you focus on the notifications that are relevant to you! 🎉
When you subscribe to a repository in Microsoft Teams or Slack, you will now see yourself mentioned in the notifications where you are referred and needs your attention.
As you receive notifications for Issues, PRs, Discussions and Deployments, here are the cases when you will be mentioned.
Assignee in an Issue
Reviewer for a PR
Mentioned in a PR/Issue description/comment/discussion
A CODEOWNERS file defines the users or teams responsible for different parts of your repository, and helps ensure the right people are included in pull request reviews. We've shipped some improvements that make it easier to work with CODEOWNERS!
Surfacing syntax errors
Syntax errors are now surfaced when viewing a CODEOWNERS file from the web. Previously, when a line in a CODEOWNERS file had a syntax error, it would be ignored or in some cases cause the entire CODEOWNERS file to not load.
GitHub Apps and Actions can access the same list of errors using new REST and GraphQL APIs.
See which CODEOWNERS will be requested for review
When creating a new pull request or after pushing new changes to a draft pull request, any CODEOWNERS that will be requested for review are now listed:
This gives you an early look at who will be requested to review once the pull request is marked ready for review.
Comment on the same line
Comments in CODEOWNERS files can now appear at the end of a line, not just on their own line:
The GitHub Enterprise Server 3.4 Release Candidate is available. This release brings over 60 new features including reusable workflows for GitHub Actions, Ruby support for GitHub Advanced Security Code Scanning, and a host of improvements for security, compliance and administration teams.
Release Candidates are a way for you to try the latest features at the earliest time, and they help us gather feedback early to ensure the release works in your environment. They should be tested on non-production environments.
This release adds support for viewing fixed alerts to the GraphQL API. This update also adds the ability to access and filter by state, as well as access unique numeric identifier.
The additions include these new fields to a RepositoryVulnerabilityAlert:
number
fixed_at
fix_reason
state
And we're adding the ability to filter by state on the vulnerability alert object.
We've gotten a lot of feedback from users that it's hard to differentiate multiple codespaces in the same repo, especially if they're on the same branch. To make it a little easier to tell codespaces apart, we've started automatically creating "friendly" (and fun) names for your codespaces.
If you don't like our names, we're also working on the ability for users to re-name their codespaces.
GitHub Advanced Security customers can now dry run custom secret scanning patterns at the repository level. Dry runs allow admins to review and hone their patterns before publishing them and generating alerts.
Admins can compose a pattern then 'Save and dry run' to retrieve results from their repository. The scans are fast – typically just a few seconds – but GitHub will also notify admins via email when dry run results are ready. Organization and enterprise-level dry runs will follow shortly.
In February 2020 we announced the deprecation of the general purpose "Delete reactions" REST API in favor of separate REST APIs for each place reactions can be applied. The old endpoint has been removed, which sets us up to scale and support the Reactions API better in the long run.
GitHub gists now only show their 30 most recent comments when first displayed. You can click Load earlier comments… to view more. This allows gists that have many comments to appear more quickly.
Today, we’re shipping improvements to Dependabot alerts that help you more easily understand and remediate vulnerabilities from dependencies in your codebase.
Persisted Dependabot alerts
Developers can now view alerts that have been fixed in the Dependabot alerts UI.
Included changes:
Starting today, fixed Dependabot alerts will now persist and continue to appear under the “closed” tab in the UI
All individual alerts now have unique numeric identifiers.
Ungrouped alerts
Previously, Dependabot alerts displayed multiple security advisories grouped by package. Dependabot alerts will now represent a single advisory, rather than being grouped by package.
Included changes:
Alerts are now displayed individually (one per advisory and manifest)
Previous alert details pages will redirect to a filtered list view by the package name
Alert titles will now be more useful to developers and show information about the advisory, rather than just the package name.
This update will not affect Dependabot alert email digests or notifications, Dependabot pull requests, or the GraphQL API.
Learn more about the improvements we’re making to Dependabot alerts in our latest blog post, or read our documentation.
GitHub Advanced Security customers can now view all their Dependabot alerts in the organization security tab. This view is available to organization owners and members of teams with the security manager role.
A light high contrast theme, with greater contrast between foreground and background elements, is now generally available to all github.com users. Navigate to the "Appearance" page in your profile settings to choose the light high contrast theme.
A VS Code light high contrast theme matching the official github.com theme is also now generally available. To start using the new theme, go to the VS Marketplace, click on the "Install" button, and select your preferred theme in VS Code.
GitHub can display several common image formats, including PNG, JPG, GIF, PSD, and SVG, and provides several ways to compare differences between versions. Now when reviewing added or changed images in a pull request, previews of those images are shown by default:
Previously, you would see a message indicating that binary files could not be shown and you would need to toggle the "Display rich diff" option.
Users can now retrieve all their code scanning alerts at the GitHub organization level via the REST API. This new API endpoint supplements the existing repository level endpoint.
This API is available on GitHub.com starting today and will also be available to GitHub Enterprise Server users starting version 3.5.
The ability to customize the command palette’s keyboard shortcuts is now available to all github.com users in beta. Customize the keyboard shortcuts for opening the command palette in search and command modes in the Accessibility section of your user settings.
The Update branch button on the pull request page lets you update your pull request's branch with the latest changes from the base branch. This is useful for verifying your changes are compatible with the current version of the base branch before you merge. Two enhancements now give you more ways to keep your branch up-to-date.
Update your pull request branch by rebasing
When your pull request's branch is out of date with the base branch, you now have the option to update it by rebasing on the latest version of the base branch. Rebasing applies the changes from your branch onto the latest version of the base branch, resulting in a branch with a linear history since no merge commit is created.
To update by rebasing, click the drop down menu next to the Update Branch button, click Update with rebase, and then click Rebase branch.
Previously, Update branch performed a traditional merge that always resulted in a merge commit in your pull request branch. This option is still available, but now you have the choice.
Note: Because rebasing rewrites the history of the branch, if you are working with the branch locally, you will need to fetch it and do a hard reset to ensure your local branch matches the branch on GitHub.com.
A new repository setting lets admins opt into having the Update branch button always available whenever a pull request's branch is not up to date with the base branch. Previously, this button was only available when the Require branches to be up to date before merging branch protection setting was enabled.
Repository admins and maintainers can manage the Always suggest updating pull request branches setting from the Pull Requests section in repository settings.
