New options for controlling the default commit message when merging a pull request

In May we shipped a setting for including the pull request title in the default commit message presented to users when squash merging a pull request. We just shipped more options for customizing the default commit message, including using the pull request's description! You can also now customize the default commit messages for merge commit merges. The goal is more predictable, consistent, and useful commit messages for your pull requests, which translate to a more useful Git commit history.

How it works

From repository settings, a maintainer or admin can choose the default format for commit messages produced when merging pull requests:
image

This selection is used to form a default commit message that gets presented to users on the pull request page when merging a pull request. For example, assume Default to pull request title and description is selected and a user clicks to merge a pull request with this description:
image

The default commit message will include the pull request's title and description:
image

The user can then accept this commit message or make changes before merging.

Options

For merge commit merging:

  • Default message: pull request number and head branch on the first line; pull request title on the third line
  • Pull request title: pull request title and number on the first line
  • Pull request title and description: pull request title and number on the first line; pull request description starting on the third line

For squash merging:

  • Default message: commit title and commit message (if the pull request contains a single commit), or the pull request title and number and list of commits (if the pull request contains multiple commits)
  • Pull request title: pull request title and number on the first line
  • Pull request title and commit details: pull request title and number on the first line; commit message (if a single commit) or list of commits (if multiple commits)
  • Pull request title and description: pull request title and number on the first line; pull request description starting on the third line

Additional details

If no message is provided when merging a pull request using the REST API or GraphQL mutation, a default commit message will be formed based on the selected message format and merge method.

The default message format can be managed using the Create a repository or Update a repository REST APIs. See the merge_commit_title, merge_commit_message, and squash_merge_commit_title, squash_merge_commit_message parameters.

Feedback

We want to hear from you! Tell us what you think and how we can make it better: https://github.com/orgs/community/discussions/30439

Learn more

Learn more about configuring merge commit merging and configuring squash merging.

Organization Billing Settings Updates for Codespaces

With this update, organization admins can manage billing settings for codespaces that are created for organization controlled repositories. Admins can choose to opt-in to the organization covering the bill for GitHub Codespaces, enable Codespaces access only for select members of the organization, allow for all organization members, or also include outside collaborators. See the screenshot below, and documentation for Enabling GitHub Codespaces for your organization for more details.

Organization Settings Billing UI

Note: The functionality of this interface remains the same. The label was updated to "Billing" where it used to be labeled "User permissions" to increase clarity. There are no changes required to your settings as a result of this update.

Any GitHub user who can clone a repository and has access to Codespaces will be able to create a codespace for it. To manage who can clone a repository in your Organization see Managing teams and people with access to your repository.

See more

SSH commit verification now supported

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."

image-of-verified-commit

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.

image-of-ssh-signing-key-ui

See more
View all changes