Previously, all attached (drag-and-dropped) images and videos on GitHub Issues, Pull Requests, Discussions, and wikis were available to view without authentication if you knew their direct URL. Now, future attachments associated with private repositories can only be viewed after logging in. This doesn’t apply retroactively to existing attachments, which are obfuscated by having a long, unguessable URL.
Email notifications sent from private repositories will no longer display images; each image is replaced by a link to view it on the web. Content inside a Git repository is not affected by this change and has always required authentication for private repositories.
As we work towards general availability of pull request merge queue, we want to thank everyone that has provided feedback❤ (keep it coming!) and let you know about some recent fixes and new API support.
See the public beta announcement to learn more about merge queue and how it can help increase velocity by automating pull request merges into your busiest branches.
🆕 API support
You can now interact with merge queue programmatically using new GraphQL APIs. Add or remove a pull request from the queue, see which pull requests are queued, get details about a queued pull request, and more. For example:
Use the mergeQueue field on Repository to list its contents or configuration. Use the mergeQueueEntry field on PullRequest to get details about a queued pull request including its state, position in the queue, estimated time to merge, and more.
🐛 Fixes
Some of the more noteworthy fixes made since the public beta launch:
Fixed: GitHub Actions workflows would not trigger on merge_group events in some repos
Fixed: failing queued pull request would remain failing even after checks were rerun and and passed
Fixed: confusing “pushed a commit that referenced this pull request” message would appear in the timeline
Fixed: commits could be pushed to queue-created prep branches (note: these commits were ignored and not merged, but it created confusion for some users)
Get started
Interested in merge queue? Learn how to get started.
Today we are announcing the public beta of repository rules! 🎉
Repository rules are GitHub's next evolution of branch protections to help make your repositories more secure and compliant at scale.
Rules allow you to easily define protections for branches and tags in your repositories and, if you are a GitHub Enterprise Cloud customer, to enforce them across your organization. It is also easier for everyone collaborating on your repositories to know what rules are in place.
Creating rules
At the core of rules is the ability to define rulesets. A ruleset is a collection of rules that are enforced together. For example, you could require that all commits to a branch are signed and that those commits have two reviewers. Rulesets can also be applied to tags, allowing you to enforce rules on releases.
The ruleset page is the central place to view and manage all the rules for a repository. It shows the rules that are currently in place and allows you to add new rulesets or edit existing ones.
When creating a ruleset, you define its enforcement status as active or disabled. Active rulesets must pass for a commit to be merged, while disabled rulesets are not enforced; they will not prevent merges but allow admins to craft rules before enforcing them.Enterprise Cloud customers can also evaluate rulesets: a "dry run" mode for understanding the impact of new rules before they are active and enforced.
It's also easier to target branches and tags in rulesets, with options to select the default branch, all branches, and branches or tags that match an fnmatch pattern. You can add multiple patterns to a ruleset to apply it to different branch and tag naming styles.
Viewing the rules
You can always know what rules are in place for a repository.
Anyone with read access to a repository can view its rules and what they mean. The rulesets overview is linked from the branches page by clicking the shield icon, and from a pull request, and from the output of the Git CLI when rules block a push.
From here, you can filter rules by branches or tags to understand how a rule might be enforced on your next push.
Getting Started
Repository rules are now available to all GitHub cloud customers. To get started, visit the documentation to learn how to enable and use rules. For Enterprise Cloud customers, visit the documentation to learn about organization rulesets and more.
We want to hear from you on how we can improve repository rules! Join the conversation in the repository rules public beta discussion.
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
Commenting on files (including deleted, binary, and renamed files) in a pull request is now generally available on the web and GitHub Mobile! A special thank you to everyone that provided feedback during the public beta.
API support is also now available. See create a review comment (REST API) or addPullRequestReviewThread (GraphQL mutation) for more details on commenting on files. A new "subject type" field is also now returned by other APIs indicating whether a comment is on a line or file.
GitHub users write a lot of Markdown; so much so that we render 2 billion Markdown files everyday; at peak times, we're processing 1,300 Markdown files a second! Any opportunity we have to shave a few seconds off of the Markdown authoring experience on GitHub is time well-spent.
Introducing Markdown Helpers powered by Slash Commands
To use Markdown Helpers, simply type / on Issues, Pull Requests, or Discussion descriptions/comments and use the subsequent dialog to choose from a number of useful Markdown shortcuts.
Use shortcuts like /table to make Markdown tables a breeze, or /details to make selectively showing content to readers much easier than remembering the HTML formatting.
As part of our first release, we've included 6 out-of-the-box features which we hope will help teams author Markdown faster and with less context switching:
Code Block
Support for language-specific syntax highlighting
Details
Specify details that the reader can open and close on demand
Saved Replies
Access your saved replies directly from Slash Commands
Table
Easily insert Markdown Tables
Templates
Easily populate your Repository's Issue or Pull Request templates directly from Slash Commands!
Commenting directly on a file in a pull request (not just a specific line) is now available in public beta! 🎉
With this capability you can now comment on deleted, binary (including images), and renamed files in a pull request. You can also comment generally about a changed code file without having to attach the comment to a specific line.
How it works
To comment on any file in a pull request, click the Comment on this file button in the header of the file (next to the Viewed checkbox):
Comments on files appear in the Files Changed and Conversation tabs and can be replied to and resolved like regular review comments.
Tell us what you think
This feature is currently in public beta, with GitHub Mobile and API support coming soon.
Rich diffs of Jupyter Notebook files in pull requests are now available in preview. With the feature preview enabled, you can compare cell-level inputs and outputs (including images), as well as notebook and cell metadata, thanks to nbdime. Check it out:
The rich diff functionality will need to be enabled via the Feature Preview menu found when clicking on your avatar. Click here to learn more about feature previews and how to enable it. Please note that this is an early-access feature and there are some limitations; most notably, you cannot currently comment on lines in rich diff mode and will need to toggle the source diff to do so.
We'd love to hear from you! Once you try it out, let us know what you think in this feedback discussion. Stay tuned for future updates!
Note: If you were previously enrolled in the private beta for this feature and no longer see rich diffs, you may have to re-enable the feature preview via the menu.
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
You can now create a custom role to manage branch protections without having to grant the Admin role. Previously, to manage 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 Edit repository rules permission, allowing just the right amount of access.
Today we are announcing the public beta of pull request merge queue for repos on GitHub Enterprise Cloud and open source organizations! 🎉
Merge queue helps increase velocity in software delivery by automating pull request merges into your busiest branches.
Before merge queue, developers were often required to update their pull request branches prior to merging to ensure their changes wouldn't break the main branch when merged. Each update resulted in a fresh round of continuous integration (CI) checks that would have to finish before the developer could attempt to merge. If another pull request got merged, every developer would have to go through the process again.
Merge queue automates this process by ensuring each pull request queued for merging is built with the pull requests ahead of it in the queue.
Queueing a pull request to merge
If your pull request targets a branch that uses merge queue, instead of merging your pull request directly when it meets the requirements to merge, you will add it to the queue by clicking Merge when ready from the pull request page or from GitHub Mobile.
The queue then creates a temporary branch that contains the latest changes from the base branch, the changes from other pull requests already in the queue, and the changes from your pull request. CI then starts, with the expectation that all required status checks must pass before the branch (and the pull requests it represents) are merged.
If a queued pull request has merge conflicts or fails any required status check, it is automatically removed from the queue when it reaches the front, and a notification is sent. Once the problem is resolved, it can be added back to the queue.
The queue details page, which can be accessed from the Branches page or pull request page, shows the pull requests in the queue and status for each, including the required status checks and estimated time to merge. It also shows how many pull requests have been merged and the trend over the last 30 days.
Depending on your permissions, you can also remove a pull request from the queue or clear the queue from this page.
Getting started
Merge queue can help improve overall velocity and avoid manual branch updates that impact developer productivity. Learn more about how to enable merge queue on your busiest branches.
A GraphQL mutation is now available for reverting a merged pull request: revertPullRequest.
Like the revert action on the pull request page in the web, calling this API creates a new pull request that reverses the changes made by the merged pull request.
Require approval from someone other than the last pusher
Now, before a pull request can be merged, you can require it to be approved by someone other than the last pusher.
Meaning, the most recent user to push their changes will need a pull request approval regardless of the Require approvals branch protection. Or in the case of 1 approval required, someone other than the last user to push their changes will also need to approve. If the approvals come from other folks than the last pusher, those two approvals will be sufficient.
Lock branch
This allows for branches to be locked, prohibiting changes. You can lock a branch allowing you to have a maintenance window and prevent changes, or to protect a fork so it only receives changes from its upstream repository.
To use this feature in a branch protection rule, enable Lock branch.
On September 5, 2022, we reverted a recent change to our indirect pull request merge logic that was causing some pull requests to be incorrectly marked as merged. This could happen if a pull request's head branch was force pushed and resulted in the pull request showing no new commits compared to the base branch. The original change went live on August 1, 2022 and caused confusion about why some pull requests were marked as merged by a contributor who did not have the necessary permissions. It also had the side effect of removing the "first time contributor" flag from these contributors without them having made an accepted contribution by the repository maintainers. Depending on repository settings, this could have allowed first time contributors to run GitHub Actions workflows based on their branches.
At no point were users able to push changes or merge pull requests in repositories to which they did not have appropriate authorization. After the change was reverted, GitHub conducted an investigation into any bypasses of the "first time contributor" flag and found no evidence of abuse.
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
The author of the Git commit created when squash merging a pull request is now shown before merging. Previously, the commit author was only shown when merging with a merge commit.
Also, if the user merging the pull request also opened it and has multiple email addresses configured, a drop-down now lets them choose a different email address to use for the commit's author.
These improvements are designed to ensure Git commits created by squash merging are associated with the correct email address.
When GitHub creates merge commits, like to test whether a pull request can be merged cleanly or to actually merge a pull request, it now uses the merge-ort strategy. merge-ort is a relatively new Git merge strategy that is significantly faster (for example, complex merge commits that previously took 5 or more seconds to create are now created in less than 200 milliseconds) and addresses subtle correctness issues found in the merge-recursive strategy. And because merge-ort is the default merge strategy in the latest releases of Git, merge results are now more predictable and consistent between your local machine and GitHub.
When opening a pull request from a comparison that only includes one commit, GitHub defaults the title and description to the subject line and body of that commit's message. Authors who write detailed git commit messages that adhere to the widely accepted convention of wrapping at 72 characters per line may have noticed that this can result in strange formatting because of how GitHub Flavored Markdown treats newlines.
We now take and automatically reformat the commit message when suggesting the pull request description, making it look just as good as the commit message it came from when viewed on github.com, GitHub Mobile, and other tools.
Previously, we announced a change to how <num> parameters work for autolink references, switching from numeric to alphanumeric IDs. We heard from a number of customers who still need numeric identifiers. Now when creating an autolink reference, you can use an alphanumeric or numeric identifier.
Autolinks are available in repositories with GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub Enterprise Server. For more information, see GitHub's products.
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:
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:
The default commit message will include the pull request's title and description:
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.
This feature is available to repositories enrolled in the Pull Request Merge Queue beta.
A new webhook event and GitHub Actions workflow trigger (merge_group) makes it easier to run required status checks on merge groups created by merge queue. A merge group includes the changes from one or more pull requests and must pass the status checks required by the target branch.
A merge_group webhook event, which currently has one supported action (checks_requested), is sent after a merge group is created and informs receivers, including GitHub Actions, when status checks are needed on the merge group. The event payload includes head_sha, the commit SHA that should be validated and have status reported on using check runs or commit statuses. For GitHub Actions, status is reported automatically at the conclusion of jobs in the triggered workflow.
To trigger a GitHub Actions workflow for a merge group, the merge_group trigger should be used. The following example triggers on individual pull requests and merge groups targeting the main branch:
# Trigger this workflow on individual pull requests and merge groups that target the `main` branch
on:
pull_request:
branches: [ main ]
merge_group:
branches: [ main ]
A push event is still sent when a merge group branch is created, and will trigger a GitHub Actions workflow. However, unlike a merge_group event, a push event does not include the target branch of the merge group.
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.
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.
Comparing commit comments and review comments
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.
What changed
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.
What did not change
This change did not impact a user’s ability to add, view, or manage comments on individual commits.
Users can still add comments to individual commits or changed lines in a commit
Users can still review pull requests one commit at a time and add review comments
Commit comments still surface on the commits listing page
Commit comments still surface at the bottom of the commit page
Commit comments are still accessible from the Commits tab of the pull request page
Commits pushed to a pull request head branch still surface in the timeline and on the Commits tab of the pull request page
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.
