Previously, when you forked a repository the fork name would default to the same name as the parent repository. In some cases, that wasn't ideal because you wanted the fork to have a different name. Your only option was to rename the fork after it was created. Now you can customize the fork name at the same time you're creating it.
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!
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.
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.
Comments in CODEOWNERS files can now appear at the end of a line, not just on their own line:
*.js @js-owner # All JavaSript filesLearn more about CODEOWNERS files.
We have introduced a new policy setting that controls whether GitHub Actions can approve pull requests. This protects against a user using Actions to satisfy the "Required approvals" branch protection requirement and merging a change that was not reviewed by another user.
To prevent breaking existing workflows Allow GitHub Actions reviews to count towards required approval is enabled by default. However, an organization admin can disable it under the organization's Actions settings.
Instead of allowing all or no users to force push, admins can now be selective about who can force push to a repository.
The image below shows how in the past, admins could use a branch protection rule to allow force pushes for everyone or no one, including admins:
This all-or-nothing approach didn't support limiting force pushes to select users or teams of an admin's choosing. For example, you might have wanted to allow only a few people to force push, or you had an automated process that solely needed to force push.
Now, you can be specific about the people and teams who are allowed to force push. As shown in the image below, select Allow force pushes and Specify who can force push. Then, search for and select the people and teams who should be allowed to force push.
For more information, visit Managing a branch protection rule.
Now, only admins can rename branches that are protected by branch protection rules.
GitHub allows repository collaborators to rename every branch in a repository, with the exception of the default branch.
When a collaborator renames a branch, any non-wildcard branch protection rules that apply to that branch are also changed to match the branch's new name.
Because only admins can modify branch protection rules, renaming of a protected branch is now limited to admin users.
For more information, visit Renaming a branch and Managing a branch protection rule.
You can now control which GitHub App a required status check is provided by. If status is then provided by a different app or by a user via a commit status, merging will be prevented. This ensures all changes are validated by the intended app.
Existing required status checks will continue to accept status from any app, but can be updated to only accept status from a specific app (see Editing a branch protection rule). Newly-added required status checks will default to the app that most recently reported the status, but you can choose a different app or allow any app to provide the status.
For more information see our documentation about protected branches.
Administrators can now allow specific users and teams to bypass pull request requirements.
For context, this image shows how administrators can use branch protections to require pull requests for all changes to a branch:
This is a good practice, but you may want to make exceptions to this rule for specific people and teams. For example, if you have an automated process that calls GitHub APIs to make changes in a repository, you may want to permit that automation to make changes without creating a pull request.
Now, when you require pull requests and their related protections for a branch, you can specify people and teams who should be free from those requirements. As shown in the image below, select Allow specific actors to bypass pull request requirements. Then, search for and select the people and teams who should be allowed to bypass the requirements.
For more information, visit Managing a branch protection rule.
You can now require that all changes to a protected branch are made using a pull request, but without requiring reviews. This can be useful when you want to use pull requests for tracking purposes or to simplify your continuous integration (CI) configuration, but don't want to gate merging on review.
Previously, you could create a branch protection rule that required pull requests with approving reviews before commits could be merged into a branch. When pull requests were required, approving reviews were also required. This didn’t meet the needs of users who wanted to require pull requests for tracking purposes or CI validation, but who didn’t want their ability to merge to be gated by approving reviews.
Now, requiring pull requests and requiring approving reviews are separate options of protecting a branch. For example, you can now require pull requests without requiring reviews, or with requiring approving reviews. This flexibility lets you choose what is best for you and your branches.
For more information, visit Managing a branch protection rule.
A warning is now displayed when a file's contents include bidirectional Unicode text. Such text can be interpreted or compiled differently than it appears in a user interface. For example, hidden, bidirectional Unicode characters can be used to swap segments of text in a file. This can cause code to appear one way and be interpreted or compiled another way.
This security issue is the topic of the Common Vulnerabilities and Exposures (CVE) publication: CVE-2021-42574. If your use of bidirectional Unicode characters is intentional and not malformed, you can ignore the warning.
To review a file for which this warning is displayed, open it in an editor that will display the hidden, bidirectional Unicode characters, like Visual Studio Code which highlights the characters by default. Then, verify that the characters are necessary and not disguising text that will be interpreted or compiled differently than it appears.
For more information, refer to Trojan Source: Invisible Source Code Vulnerabilities.
You can now set whether a repository allows forking when creating or updating it using either the REST or GraphQL API.
Previously, APIs for creating and updating repositories didn't consider the fields allow_forking (REST) or forkingAllowed (GraphQL). Now, this field can be set before invoking the API to configure whether a repository allows forking.
For reference, see documentation for the REST API and GraphQL API.
Previously, in the code browser, when you were searching for a branch by typing its name, a branch with the exact name of what you typed could appear at the bottom of the list of matching branches. This made it hard to recognize and sometimes requiring scrolling to the end of the list to select the branch.
Now, when a branch name exactly matches what you type in the search box, it appears at the top of the list of matching branches for faster recognition and selection.
Public repositories now have a public label next to their names like private and internal repositories do.
Previously, repositories had a label next to their name that indicated if they were private or internal, but there was no label if they were public. This led to people not recognizing that a repository was public and accidentally committing private code to it. Now, public repositories have a public label next to their name like private and internal repositories do.
Learn more about repository visibility.
When a new tag is created, the push webhook payload will now always include a head_commit object that contains the data of the commit that the new tag points to. In other words, the head_commit object will always contain the commit data of the payload's after commit.
Previously, during tag creation, there were certain circumstances where the head_commit would contain the data of a different commit.