We updated the web UI to make keeping forks in sync with their upstream repositories more intuitive. "Fetch upstream" has been renamed to "Sync fork," which better describes the button's behavior. If the sync causes a conflict, the web UI prompts users to contribute their changes to the upstream, discard their changes, or resolve the conflict.
GitHub now supports SSH commit verification, so you can sign commits and tags locally using a self-generated SSH public key, which will give others confidence about the origin of a change you have made. If a commit or tag has an SSH signature that is cryptographically verifiable, GitHub makes the commit or tag "Verified" or "Partially Verified."
If you already use an SSH key to authenticate with GitHub, you can now upload the same or a different key pair’s public key to use it as a signing key. There is no limit to the number of signing keys you can add to your account. For more information, visit SSH Commit Verification in the GitHub documentation.
You can now create a custom role to bypass branch protections without having to grant the Admin role. Previously, to bypass branch protections you had to be an Admin which provides additional permissions that may not be needed. For tighter control of Admin permissions, you can now craft a custom role that has the Bypass branch protections permission, allowing just the right amount of access.
To enforce branch protections for all Admins and roles with the "Bypass branch protections" permission, enable Do not allow bypassing the above settings in your branch protection rules.
This permission differs from the Push commits to protected branches permission, which allows pushing to a protected branch, but branch protection rules will still apply and could result in a push being denied.
For more information, visit Managing custom repository roles for an organization in the GitHub documentation.
We appreciate feedback on this and other topics in GitHub's public feedback discussions.
Code review on GitHub has evolved a lot since we introduced the ability to comment on an individual commit in 2008. Users today can propose a change using a pull request, which provides a first-class experience for reviewing, discussing, evolving, and ultimately accepting or rejecting a change. While pull requests are the recommended way to review and discuss proposed changes, commenting on individual commits is still currently supported.
We recently rolled out a change to no longer show comments added to individual commits (comments added outside the context of a pull request) on the pull request timeline. Previously, if a pull request happened to include a commit that had commit comments, those comments would appear on that pull request’s timeline. Users often reported that these comments were irrelevant to the pull request or caused confusion when added by someone not involved in the review.
Note: this change does not impact the ability for users to comment on individual commits or review a pull request one commit at a time.
To help understand this change, let’s compare commit comments with pull request review comments.
A commit comment is a comment added by a GitHub user to an individual commit or to a line of a file changed in a commit. Commit comments are stored on GitHub and surface in various places in the GitHub UI, including at the bottom of the commit page (/:org/:repo/commit/:sha):
A commit comment is associated with a commit. A commit comment cannot be added from the pull request page and cannot be replied to or resolved like a pull request review comment because it does not belong to the pull request. A commit comment can be indirectly associated with a pull request if that pull request includes the commit.
A pull request review comment is a comment added by a GitHub user to a changed line (or the lines surrounding it) in a pull request. Review comments are usually added from the Files changed or Commits tab of the pull request page and are directly associated with the pull request.
Unlike commit comments, pull request review comments do not surface outside the context of the pull request since they belong to the pull request.
Prior to this change, comments on individual commits (made outside the context of the pull request) would appear in the timeline of any pull request that included that commit:
With this change, commit comments (like the highlighted 029541b comment) no longer appear in the pull request timeline.
The timeline events REST and GraphQL APIs also no longer return commit comments associated with any commits included in the pull request.
This change did not impact a user’s ability to add, view, or manage comments on individual commits.
There was also no impact to commit messages, i.e. the message stored with the Git commit. Commit messages continue to surface everywhere they previously surfaced, including on the pull request page.
If you have feedback or questions about this change, let us know here: https://github.com/orgs/community/discussions/28924
The repository file finder is a convenient way to jump to a specific file by typing part of its path. It can be accessed by pressing t or using the “Go to file” button.
The file finder hides files in directories like vendor/ and build/ by default. These exclusions can now by customized using linguist attributes in a .gitattributes file. For example:
vendor/** linguist-vendored=false
build/** linguist-generated=false
Learn more about the file finder
Learn more about .gitattributes
Previously, when creating a fork all branches from the parent repository were copied to the new fork repository. There are several scenarios where this is unneeded, such as contributing to open-source projects. When all branches are copied, it could result in slow repo cloning and unnecessary disk usage. With this new feature, only the default branch is copied; no other branches or tags. This may result in faster clones because only reachable objects will be pulled down.
If you want to copy additional branches from the parent repository, you can do so from the Branches page.
Previously, when creating an autolink reference for a repository, you could only use a numeric identifier in the <num> parameter. This format didn't support integration with platforms that use alphanumeric identifiers, like the last segment of this Trello card URL: https://trello.com/c/3eZr2Bxw. Now you can create an autolink with an alphanumeric identifier.
Any previously created autolinks will continue to support only numeric identifiers so that they continue working as before. Only newly created autolinks will support alphanumeric identifiers.
Autolinks are available in repositories with GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub Enterprise Server. For more information, see GitHub's products.
Learn more about autolinks at Configure autolinks in the GitHub documentation. We appreciate feedback on this and other topics in GitHub's public feedback discussions.
A dropdown has been added to the Fork button to help you quickly find your forks of a repository. This includes forks in your personal account and in organizations that you're a member of.
This feature was inspired by Refined GitHub – an impressive open source project maintained by @fregante. The feature was requested of GitHub through the GitHub Stars program.
Read more about forking a repository in the GitHub documentation.
We appreciate feedback on this and other topics in GitHub's public feedback discussions.
Previously, three aspects of repository forks caused friction to innersource collaboration and administration:
These obstacles have been addressed with the following new features. We’re always looking for new ways to improve repository collaboration and we welcome your ideas.
Previously, a repository could be forked only to a different organization or user account.
Now, a repository can be forked to the same organization as its parent repository, addressing situations where people are working in one organization and don’t want to fork a repository to a different organization or user account.
Previously, when a repository with internal visibility was forked, the fork was automatically created in the person’s personal account space and its visibility was changed to private.
Now, people can fork an internal repository to an organization in the same enterprise, and the fork will retain its internal visibility. When forking an internal repository, you can choose which of the enterprise’s organizations should receive the fork – similar to forking a public repository, except that:
Previously, enterprise owners couldn’t restrict where repositories in the enterprise could be forked. This was important for them to keep confidential repositories from accidentally being forked to an exposed location.
Now, enterprise owners can control where enterprise members can fork repositories. Forking can be limited to preset combinations of enterprise organizations, the same organization as the parent repository, user accounts, and everywhere.
Learn more about working with forks, or enforcing a policy for forking repositories, in the GitHub documentation.
We appreciate feedback on this and other topics in GitHub’s public feedback discussions.
This beta feature allows repository admins to block Git pushes to a repository when they are potentially destructive.
Developers have had branches deleted from their repository when someone pushes changes with Git's --mirror option. The --mirror option is potentially destructive because it makes the remote repository exactly match the local clone. When run by accident, if the remote has more branches or different data than the local clone, many branch deletes and force-pushes can happen at the remote without any warning. This is often embarrassing for the one who pushed and a big challenge to recover from. Here's a real-world example: git push origin –mirror deleted all of my colleagues' branches.
This destructive situation can usually be identified by multiple branch or tag updates being pushed at the same time. The new beta feature being announced here allows admins to block potentially destructive pushes by limiting the number of branches and tags that can be updated by a single push. This can prevent or limit the loss of data.
To use this beta feature, click Settings in a repository that you are an admin of. Next, select General (the default, top-most tab). Then toggle the setting named Limit how many branches and tags can be updated in a single push as shown below. Set the number appropriately for your needs. We recommend the default maximum of 5 branch or tag updates allowed in one push. The minimum value is 2 since two branch updates are required by Git to rename a branch in a single push: delete branch and create branch. Lower numbers are more restrictive of which pushes are allowed, and higher numbers are less restrictive but have more potential for being destructive. As part of this feature's beta, we'd like to learn which number works best for you.
We appreciate feedback on this and other topics in GitHub's public feedback discussions.
Previously, it was difficult to create a new branch from the GitHub UI. Now you can create a branch on the Branches overview page. Just click the New branch button, shown here:
Then, specify the new branch name and source:
Read more about creating a branch. We appreciate feedback on this and other topics in GitHub's public feedback discussions.
Organization owners and repository admins can now require developers to sign off on commits made through GitHub's web interface. Also, it is now easier for developers to complete a signoff in the web interface.
Note: Signing off on a commit is different than signing a commit, such as with a GPG key.
The Git command line interface has a --signoff option that developers can use to sign off on their commits. Many open-source organizations require developers to sign off on their changes to affirm compliance with repository rules and licensing. Git's --signoff option appends a specially formatted line to the commit message, as shown here:
Signed-off-by: Mona Lisa <mona@github.com>This text is what constitutes a signoff. It is often called a “DCO signoff” because the most common signoff agreement is the Developer Certificate of Origin (DCO) from the Linux Foundation.
Open-source projects often use pull request checks to block commits from being merged unless they're signed off. Here’s an example of a commit being blocked in the open-source Gradle Profiler repository, which uses the Probot GitHub App to check whether all of a pull request's commits are signed off:
This problem is more likely when committing from GitHub's web interface where Git’s --signoff option isn't available. To sign off there, developers must manually add the Signed-off-by: text to their commit message. That's easy to overlook or misformat, resulting in the commit being blocked from merging. Resolving this situation can be complicated and slow developers down, as shown in these instructions to fix one commit:
In the words of one open-source contributor:
🤦 As a pull request reviewer, this is my biggest pain point. If someone forgets to manually sign off on a commit in the web UI, the pull request check fails and the only resolution is to rebase or squash and force push to fix the commit message. Either way, the review history becomes unclear. This is high friction for new and infrequent contributors and people forget.
Organization owners and repository admins can now require developers to sign off on commits made through GitHub's web interface, such as when editing a file or merging a pull request.
Also, it is now easier for developers to complete a signoff in the web interface, resulting in fewer commits being blocked from merging and less time spent resolving blocked commits.
Organization owners can configure an organization-level setting to require sign off on commits made through the web interface. To do so, click Settings in an organization that you are an owner of. Next, in the navigation under Code, planning, and automation, select Repository and then Repository defaults. Finally, under Commit signoff choose All repositories to require sign off on web-based commits in all repositories in the organization, as shown below. Alternatively, select No policy to disable the setting so that sign off will not be required unless enabled at the repository level.
Repository admins can toggle a similar repository-level setting. To do so, click Settings in a repository that you are an admin of. Next, select General (the default, top-most tab). Then toggle the setting named Require contributors to sign off on web-based commits as shown below. This setting will be overridden by the organization-level setting unless the organization has No policy selected.
When the setting is enabled, the web interface will inform developers that their action of committing will also constitute signing off, as shown below. Like using Git's --signoff option on the command line, signing off in the web interface will automatically append the Signed-off-by: text to the commit message.
Related to this feature, GitHub is planning a Git push policy setting that blocks commits from even entering a repository if they are not signed off. This will apply to commits made in GitHub's web interface or pushed from the Git command line or another Git client.
We appreciate feedback on this and other topics in GitHub's public feedback discussions.
GitHub will now verify Git commit signatures and show commits as "Verified" even if their public GPG signing keys are expired or revoked (but not compromised). You can also upload GPG keys that are expired or revoked to your GitHub user profile.
Using GPG or S/MIME, you can sign Git commits. These commits are marked "Verified" in GitHub's web interface, giving others confidence that they come from a trusted source because they carry their committer's signature.
GPG keys often expire or are revoked when no longer used. Previously, when a public GPG key stored in a GitHub user profile was expired or revoked, all commits that had ever been signed with that key would be shown as "Unverified" on GitHub. That raised unnecessary concern since the commits were validly signed before their key was expired or revoked. Now, when a user's GPG key expires or is revoked for a reason other than being compromised, GitHub will continue showing commits that were previously signed with that key as "Verified." You can also upload GPG keys that are expired or revoked. Besides maintaining trust in commits’ sources, this allows GPG keys to be added or rotated for greater security without losing the “Verified” status of previously signed commits.
For more information, visit About commit signature verification in the GitHub documentation.
We appreciate feedback on this and other topics in GitHub's public feedback discussions.
We’ve made it easier to discover multiple licenses within an open source repository. First, navigate to the **About** sidebar on the repository page to see if the repository contains any licenses. If it does, they’ll be listed underneath the README file.
If only one license is detected, the link will take you directly to that license file. If more than one license is present, click on the list of licenses to display a dialog containing all of the licenses available at the root level of the repository. Then you can select from the dialog which license you’d like to navigate to.
With the use of an open source Ruby gem called Licensee, we detect license files and compare them to a short list of known licenses. Learn more about how repositories on GitHub are licensed.
Adding an open source license to your repository ensures that others can use, copy, modify and contribute back to your project. If your repository doesn’t have an open source license and you want others to get involved, you can learn more about adding one here. The dialog will match any top-level licenses with a variation of LICENSE, COPYING, OFL and PATENTS, including file extensions (i.e. LICENSE-MIT, LICENSE-GPL).
Previously, some branch protections only allowed exceptions to be granted to users and teams. Now, GitHub Apps can also be granted exceptions to any branch protection that supports exceptions.
Admins can create branch protection rules to enforce certain workflows for branches, such as requiring a pull request before changes can be merged to a branch. This is a good practice, but you may want to make exceptions to a rule for specific people, teams, or GitHub Apps. For example, if you have a GitHub App that calls GitHub APIs to make changes in a repository, you may want to permit that App to make changes without creating a pull request. Previously, these exceptions could be granted to people and teams, but only some protections allowed GitHub Apps.
Now, branch protections that previously only allowed exceptions for people and teams also support GitHub Apps. When admins configure these branch protections, they can choose from a list of GitHub Apps that are installed and authorized for the repository, as shown here:
For information about branch protection rules, visit Managing a branch protection rule.
For information about GitHub Apps, visit About GitHub Apps.
We appreciate feedback on this and other topics in GitHub's public feedback discussions.