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.
It is now possible to manually select the previous release prior to generating release notes in the GitHub Releases UI.
For more information on Generating Release Notes, see the Automatically Generated Release Notes documentation.
For more information on GitHub Releases, see the GitHub Releases documentation.
Custom repository roles are now GA for GitHub.com and Enterprise Server 3.5.
Organization admins can create custom repository roles available to all repositories in their organization. Roles can be configured from a set of 35 fine grained permissions covering discussions, issues, pull requests, repos, and security alerts. Once a role is created, repository admins can assign a custom role to any individual or team in their repository.
Custom repository roles can be managed in the Repository roles tab of your Organization settings:
Custom repository roles are also supported in the GitHub REST APIs. The Custom Roles API can be used to list all custom repository roles in an organization, and the existing APIs for granting repository access to individuals and teams support custom repository roles.
To get started with custom repository roles, read the docs.