The refreshed pull request commits page, which was previously in public preview, is now generally available! This updated page improves performance, is more consistent with other pages across GitHub, and is accessible to more users.
Your feedback during the public preview helped us deliver a better experience, including better keyboard navigation. If you have additional feedback, please let us know in the GitHub Community.
A new version of the commit details page is now available in public beta!
This new page, which is enabled by default, lets you quickly understand and navigate the changes in a commit with improvements to filtering, commenting, and keyboard navigation.
Here are a few of the noteworthy changes:
up and down keys on your keyboard. A new context menu also makes it easier to comment, copy, and select.To give feedback, ask questions, or report a bug join us in the feedback discussion.
To opt out of the preview, go the Feature Preview dialog on your profile, select New Commit Details Page, and click Disable.
To learn more about viewing commits, see About commits.
The pull request commits page has been refreshed to improve performance, improve consistency with other pages, and to make the experience more accessible!
To minimize disruptions, the capabilities of the classic commits page have been maintained, with a few exceptions: you can now use arrow keys to navigate the list of commits (instead of j and k) and focus indicators have been improved for better visual distinction.
To switch back to the classic commits page, disable the “New Pull Request Commits Experience” feature preview (learn more).
To provide feedback, ask questions, learn about known issues, visit the GitHub Community feedback discussion!
We are rolling out a few minor updates to the user experience for GitHub repositories starting today, in order to be more responsive, performant and more easily accessed by a broader range of users.
Repository Overview:
Branches:
Commits:
These changes have been in a feature preview for the past few months and thanks to community insights, we’ve made several improvements that allowed us to now exit the preview, and bring these enhancements to everyone on GitHub. Join the conversation about this release in the community discussion.
New updates to the branches and commits pages are now in feature preview. These updates are focused on improved navigation, performance, and making these experiences more accessible.
We added clarity to the list header explaining what each section of the branches page does. Stale branches are now hidden by default to speed up page load times.
You can now filter commits by a date range and collapse the list per day to find the commits that matter to you quickly.
Click here if you have feedback and let us know in our community discussion.
We've now made it easier to understand changes to your repositories with the new activity view. Historically viewing pushes to a repository required contacting GitHub support. This new activity view gives users with read access the ability to self-serve insights to a repository and all of its changes.
You can access the Activity view from the main page of a repository by clicking "Activity" to the right of the list of files.
You can also access the activity view from the Branches page of any repository by clicking on the activity icon.
From the activity view you can sort and filter to find exactly what you are looking for.
Here is an example of how you could use the activity view to find a force push on a particular branch, and then compare the changes to the repository before and after the push:
Learn more about the Activity view.
Already using the activity view? We'd love to hear your feedback.
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 <[email protected]>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.
It's now possible to ignore revisions in the blame view using a .git-blame-ignore-revs file in the root of your repository. For more information, see "Ignore commits in the blame view".
To improve security and confidence in the authenticity of your contributions, you can flag commits and tags on GitHub.com that are attributed to you but not signed by you. With vigilant mode enabled (now available in beta), unsigned commits attributed to you are flagged with an Unverified badge. This can alert you and others to potential issues with authenticity.
The author and committer of a Git commit can easily be spoofed. For example, someone can push a commit that claims to be from you, but isn’t. Like showing a passport, committers can increase trust in their commits by signing them with a GPG or S/MIME key. And now, when you enable vigilant mode, commits will be flagged if they’re attributed to you but not signed by you. This raises attention if someone tries to spoof your identity as a committer or author. With vigilant mode enabled, all of your commits and tags are marked with one of three verification statuses: Verified, Partially verified, or Unverified.
Try it yourself! First, check out how to automatically sign your commits. Then, enable vigilant mode in your account settings:
Be sure to enable vigilant mode after you start signing your commits and tags. Once you enable it, any unsigned commits or tags that you push to GitHub.com will be marked "Unverified," including past commits.
Learn more about vigilant mode.
