Improved pull request merge experience (public preview) feedback

[willsmythe]

Tip

• See Known issues below for latest on known bugs and feature parity gaps.

Important

• Starting January 30 the improved experience will be enabled by default for some users. You can still turn it off, but if you do, please tell us why below. ❤️ ❤️ ❤️

About the new experience

To help you better understand the state of your pull request and get it merged faster, the merge experience on the pull request page has been improved! This experience is currently in public preview.

What's new

We've maintained the familiar look of the existing merge experience while incorporating several usability improvements:

• Checks grouped by status: checks are now grouped by status with failing checks prioritized at the top of the list, making it easier to identify issues that need attention
• Checks ordered alphabetically: status checks are now ordered alphabetically to make it easier to find a specific check
• Commit metadata validation: errors from failing commit metadata rules (like non-compliant commit messages) can now be corrected and retried
• Improved accessibility: consistent keyboard navigation, focus management, and landmarks help make the experience more accessible to everyone

How to turn it on (or off)

Click the Try the new merge experience link below the merge box on the pull request page to enable the improved experience:

To switch back to the classic experience, click the Switch back to the classic merge experience:

You can also toggle the experience via the feature preview dialog.

🔴 🔴 🔴 Known issues 🔴 🔴 🔴

You will run into some bugs and missing features (let us know when you do if not listed here).

Missing features

Features currently missing:

• Add your review action in the Reviewers section (workaround: navigate to the Files Changed tab and click Review changes)

Bugs

1. Unable to add PR to queue if commit metadata rules are enabled
2. Overall merge status styling is sometimes too harsh or not consistent with the current experience
3. Clicking the Resolve conflicts button results in a 404/Not Found in certain cases
4. Bypass checkbox sometimes not visible / user blocked from merging with The base branch does not accept merge commits.

Recently fixed

Full list

• FIXED 2024-11-09: Enabling auto-merge fails with a "not found" error
• FIXED 2024-11-12: Admin bypass checkbox not always appearing preventing users from bypassing merge requirements
• FIXED 2024-11-14: Styling of the Delete branch button is sometimes missing (fixed by reloading the page)
• FIXED 2024-11-22: The browser tab icon (favicon) does not currently reflect the pull request's merge status
• FIXED 2024-11-25: A page refresh is sometimes required to show latest status and correct actions/buttons (like after all checks have completed)
• FIXED 2024-11-25: Clicking Delete branch / Restore branch fails with a Couldn't update branch message (likely occurs only in PRs from forks)
• SUPPORTED: Reviews can be dismissed and re-requested
• SUPPORTED: Command line instructions are missing
• FIXEX: Restore branch button is easily confused for Delete branch (we moved the Restore branch button out of the new merge experience so the only button that will appear here is Delete branch)
• FIXED: Use natural/logical ordering for status checks to help with numeric matrix build ordering
• FIXED: In certain cases, an incorrect commit author email address will be shown when confirming merge or a different email address will be used from what's displayed
• FIXED: Misalignment/wonkiness with check status icon (Safari-only)
• FIXED: Squash and auto-mergebutton (to enable auto-merge) is too easily confused forSquash and merge` (to directly merge) because of similar text and styling *FIX IN PROGRESS
• SUPPORTED: Selecting a different commit author email when merging
• FIXED: Showing status check durations (showing how long a check has been running / took to run)

Looking for feedback 🔈 🔈

• Collapse the grouping of "passing" checks by default
• Show the grouping of "in progress" status checks above the grouping of "pending"
• In the current experience, the confirmation form (which appears after clicking "merge") replaces the entire merge experience, but is simply appended in the new experience. Like? Some options:
  • Replicate the behavior of the current experience?
  • Open a dialog?

Feedback

We want to hear from you! Post your comments, questions, likes, and dislikes below.

[codeithuman]

Where is the "Merge without waiting for requirements to be met (bypass branch protections)" checkbox?

Old

New

[otskarli]

This is amazing

[fabiomontefuscoloprotolabs]

Isn't possible to have an option to always show the checks, with no inner scroll, like a normal page?? I don't understand why it needs to be hidden

[RichoKD]

Is it just me or do the check animations use a lot of gpu power?

[nielsnl68]

It looks very perfect, when we could see this box on top of the page instead of at the bottom.

[wsmith323-cube]

The titles of the collapsable sections in the new Merge UI are not selectable. I use some of these in conjunction with a browser plugin to monitor when an automatic build is finished. Having to type the text into that tool is arduous and error prone. It didn't used to be this way. Why is it now?

[willsmythe]

Thanks for the feedback / write-up. Definitely agree. This check box appears for some users in some scenarios, but there's clearly a bug here where it's not appearing for everyone. We're investigating.

[seesharprun]

I like this feature so far, but the only transient bug I've seen is sometimes the checks show up fine while they are processing, but once all checks have passed, they all disappear. If you select the arrow to expand, it shows an empty list. I need to refresh the browser to see the passing checks.

Again, just a small client-side issue that I'm seeing in Edge 130.0.2849.68

[willsmythe]

I added this issue to the Known issues > Bugs section in the description above. Check there for updates, and to see other issues we're tracking.

[chamini2]

Again, just a small client-side issue that I'm seeing in Edge 130.0.2849.68

for a second I thought you commented your IP

[jessicaDura]

again non diversitalizing materials the only truely honest traite available to be earned.

[dub-lin]

just hoping for the best cus my time has been wasted looking for a way out of everything i put myself into just to find a better living

[niyahj]

What might cause the checks to disappear after processing?

[thomas-bc]

The "view command line instructions" can be handy. It used to be a clickable element that extends to show CLI commands. It is not anymore. Could be good to add back in?

[willsmythe]

Thanks for the feedback. This is coming! See the Known issues > Feature gaps list above.

[Tilka]

The second command of Step 1 points to the wrong repository. It should point to the repo of the branch being merged, not the repo of the branch it's being merged into. The instructions of the "classic merge experience" are correct.

[jimklimov]

@mno-ly : surprisingly, yes. I see a fair share of samaritan contributors who are helping improve FOSS projects, even if they are young and making first steps with the language or git tooling, so helping them help us is good.

A perhaps more "troublesome" category is contributors who are very much not young, and while they can share experience about the project or subject matter generally, and are comfortable about programming or documentation tools, learning new-fangled tools like git (and remembering it until the next time) is a practical problem, so cheat-sheets do help. May I live to their age and remain so eager and able to help!

[tzing]

The new look on that PR successfully merged message confused me.

Its appearance is quite similar to the message of you can click this button to delete the branch on the classic pane. This look makes me wonder if the auto delete branch feature is broken.

[DingGGu]

I think this feedback is deployed now.

[richardhj]

@willsmythe It shows "...has been merged and deleted" (see above) to me but my branch is protected (and if it would have been deleted in fact, it would be a disaster because of deployment).

[jonathan-bird]

@richardhj +1 here too

[freakyblack]

Has there been any consideration to redesign or clarify the 'PR successfully merged and closed' message to avoid confusion with the auto-delete branch feature?

[isabellabreder]

+1 here, very confusing

[kaoths]

---

The "Delete branch" button CSS/style sometimes doesn't load.
This sometimes appears after merging a PR.
It does not affect any functionalities. Just the visual issue, reloading the page fixes it.

[a-stankevich]

Same happens occasionally in Firefox, Windows

[kaoths]

Sorry for late reply, I'm seeing this on Arc browser.

[willsmythe]

This should be resolved now. If anyone is still experiencing this, let us know!

[Ivnfrolov13]

yes

[jenniyuslauw]

Are there plans to implement a more robust solution to ensure consistent rendering of UI elements across all browsers?

[getchoo]

Here is the new experience on a PR with an approval from a reviewer without write access, that has also passed all CI:

Displaying red around this feels a bit odd to me. My first thought when I see it is that CI has failed, changes have been requested, or maybe that there are required approvals/checks still being waited on? (None of these are the case in this repository, which is nixpkgs)

In comparison, the classic merge experience has a green accent:

(I also noticed the new experience shows the approval of the reviewer w/o write access. This is an awesome addition for nixpkgs, so thanks!)

The use of green lets a PR author or committer know at a glance that it should be good to merge. I'd much rather keep this behavior :)

[maples3]

As a side note, I really dislike that the passed checks are hidden, and that if I expand the successful checks, that it doesn't stay expanded on refresh or if I come back.

Sometimes GitHub doesn't run the actions for whatever reason, or it's delayed, so seeing a blank/empty box here is an internal red flag for me, whereas if all is well I expect to see a line-up of green checkmarks

[pawelma]

I also think that It shouldn't be red when there are no requested changes from the reviewers, red implies that action from author is required, but waiting for review is not an action for the author but something that reviewer should look at. As a reviewer I skipped couple PRs after this feature has been applied as I immediately assumed it's WIP and CI is failing.

[patrickherrera]

+1 on changing the use of a red colour (and the big red cross icon) even if there are no issues. This is not very user-friendly and disguises real problems. Amber/orange makes more sense, and maybe a "paused" icon instead of a cross if the only thing needed is a review

[zsojma]

+1 for not using red

[janbrasna]

As a contributor, I probably shouldn't be told (in red) that "merging is blocked" — that's not an error given my access and does not warrant the grey triangle or the red box treatment — when it just waits for someone with write access. Basically the disabled greyed-out merge button with the text "Only those with write access…" on the last line do the job of communicating I have to wait for someone to merge that. The warning above it just adds more confusion than anything else.

[asilbek-ismoilov]

Very good

[halamix2]

"Enable auto-merge" button is replaced with "Squash and auto-merge" which is broken:
Instead of marking the PR to be auto-merged it simply displays "Not Found" error below the button

Console logs just displays 404 on POST to https://github.com/<org>/<repo>/pull/531/page_data/enable_auto_merge

[willsmythe]

The team is reviewing a fix for this.

[willsmythe]

A fix for this problem rolled out on Friday! 🎉

Let us know if you're still seeing this problem.

[halamix2]

It's fixed now, thanks <3

[jfredt]

What steps were taken by the development team to address the problem, and how long did it take to deploy a fix?

[stevemayhew]

Also, would be nice to bring back showing the other options (Merge commit, etc.) that may be disabled by the repository owner. That way you know what to ask for if your preference is missing

[leoskyrocker]

it's buggy and requires a page refresh before the merge button works even when all the checks are already passing, overall it feels less real time than before

[willsmythe]

Thanks for the feedback. Definitely a problem. We're investigating.

[willsmythe]

Are there any required status checks? Or just optional? Or a mix?

[dg6862]

I have the same issue. We have several optional checks and one required.

[willsmythe]

A fix is underway for this. Should deploy by early next week.

[jcviljoen]

Hey Will 👋. I ran into a simpler case where, if you merge the base branch and the checks pass, the "enable auto merge" button stays visible until you refresh. Seemed like an extension to this feedback 🙌.

Great update btw! 🚀

[Lamparter]

Merge is not an allowed merge method in this repository.
You're not authorized to push to this branch. Visit https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches for more information.

files-community/Files#16445

Sorry for the oversized screenshot! I noticed the text merge is not an allowed merge method in this repository in a repository I don't control - I'm assuming this isn't intended and so reporting it here.

[banagale]

I just spun wheels trying to determine if I had set up my PR incorrectly, only to switch to classic merge experience and see that nothing seems to be wrong.

This language makes no sense.

[InvalidUsernameException]

Yeah, this one is weird. I'm seeing something similar on a PR that I opened on a repo for which I do not have write access. And contrary to the message the branch in question does not contain a merge-commit.

[dogshapedangel]

Ran into the same issue and spent way too much time thinking I did something wrong here when submitting a PR. The language is extremely confusing and misleading and should be adjusted.

[timshadel]

This is especially invalid if there is only 1 commit—squashing is not possible at that point.

[janbrasna]

If I don't have write access, I can't influence anything about merge strategies or branch protections. Please don't show it to me, when I won't be even shown the merge button…

(BTW aren't the first and the last issue effectively the same? Isn't it redundant if/when they are covered by the other?)

Also, don't make up issues. None of the PRs I've documented here would have a merge commit present:

so this is clearly making up stuff.

The only issue is an approval missing. That's already covered on the first line. The last line is completely irrelevant to me, when I don't have the merge button privileges. It adds no value, only misinformation. If the whole line was gone, it would actually be more helpful. (Of course for members or write level folks that's a different story, but it's absolutely non-actionable for read access people.)

[kennytv]

I like that the list of checks is grouped collapsed now, though when expanding it, I'd want all of them to be opened by default, including successful checks. In the example below, it currently only expands skipped checks:

I also feel like the red outline for awaiting reviews is a bit too aggressive, especially when coupled with removing so much green (no full checkmark as well as including skipped checks as gray in the outline).

[yorik]

Successful checks often includes diff, which important to check before approving, so keeping them easy accessible is very important.

[lessthnthree]

Yeah, when a PR is fine, checks passed, just waiting review, it immediately threw me off to see it now in red. Red I usually associate with some action required on my part to resolve.

[NathanaelGandhi]

My preference would be while checks are still running/pending/failed to either expand the checks group or have an account setting to automatically expand those groups by default. Passing checks defaulting to collapsed seems like a sensible choice as I'm not waiting on them and they would not require intervention. Therefore not seeing a list of checks screams things completed and are fine.

[saiichihashimoto]

When UI elements are collapsed, it helps because there's often something below that I'd rather not scroll to. If not, then it's not helping me consolidate space for anything. Successful checks are already on the bottom, you're not saving me any effort by keeping them collapsed by default. But you are adding a click for when I do need them.

[dustyholmes-wf]

In this thread, it seems that we have two classes of users. Those who want to see things collapsed by default and those that don't.

If you want it collapsed, you probably have a lot of jobs and just need to see what fails at a glance.
If you want it expanded, you probably have very few jobs or have a need for a successful job to be available.

Would it be so bad for this to be a remembered thing per user or repository? I collapsed successful jobs, so maybe that isn't useful to me or this repository. It seems like some elements of the new merge experience remember your choices, others do not. I'd just like to see this morph into something that is consistently useful for as many people as possible.

For me, showing successful jobs is a problem. Showing skipped jobs, is a problem. At least one of the repositories I work with has a very big workflow and that's just not something I can parse.

[spytheman]

Checks grouped by status: checks are now grouped by status with failing checks prioritized at the top of the list, making it easier to identify issues that need attention

THANK YOU 🙇🏻‍♂️ ❤️ 🥳 !

[spytheman]

I have a repository that has over 40 jobs that are commonly running and sometimes depending on what is changed, that can grow up to 76. Previously I had to scroll/hunt for the failing jobs A LOT.
The improvement in this alone, made my daily Github experience a lot better 🥳 .

[Lukeghenco]

We are glad to hear about this. GitHub developers have infinitely more than 76 on many of our repos (as do a ton of larger repositories using GitHub), so this was something we felt would really help the DX. Thank you for the feedback.

[joshhunt]

Bringing failing checks to the top is a huge win. Thanks for this 🙌

[ditman]

I came to say the same, I routinely work on a repo that has 70+ checks, and collapsing the results, and moving the failing to the top makes this much nicer :)

[maples3]

Is there any way to disable the auto-collapsing? We've had issues with Actions failing to run or delaying start, so I've built up mental memory of "no green checkmarks == something is wrong". Collapsing everything here makes it look, at first glance, like nothing has run, which is a problem that needs to be addressed. I would much prefer to have the option to keep all sections expanded here

[genintho]

Checks ordered alphabetically: status checks are now ordered alphabetically to make it easier to find a specific check

The sorting is braking. little bit when using matrix with numbers.

[willsmythe]

Totally agree. We have an internal issue tracking this. I'll add it to the list of Known issues > Planned changes above.

[willsmythe]

@genintho - can you give this another try? We rolled out a fix today to order status checks more logically.

[genintho]

@willsmythe it looks fixed! Thank you!

[jeremiah-snee-openx]

When merge queue is enabled. Seeing button for merge when ready, but PR is immediately added to merge que. Is this desired behavior?

[willsmythe]

If the PR meets the conditions to "merge" when Merge when ready is clicked, the PR will be added to the queue immeiately (and eventually merge unless it gets removed for some reason). The classic experience worked the same way, but maybe not as fast.

[brooklax]

I provided feedback a few days ago which just read "Checking for the ability to merge automatically..." because this is something I am experiencing all the time, I didn't really add more info or context as I had some work to do at the time and found this issue quite frustrating.

Anyways, now I see I have many notifications for what I posted but I am unable to find what I posted when clicking on the notification. I would also consider this a bug but I assume it wouldn't be part of the PR UX enhancement?

Here's the URL I get taken to when I click on the notification: https://github.com/orgs/community/discussions/143787#discussioncomment-12331919

[aron]

Currently the text editor field in the new commit message box does not respect the "monospace textarea" setting. See screenshot below:

[willsmythe]

Thanks for the feedback. The monospace setting only applies to markdown fields.

Font preference for plain text editors that support Markdown styling (e.g. pull request and issue descriptions, comments.)

But, it's a good suggestion. I'll open an issue to track it.

[ibraheemsaoud]

Amazing new design, big fan :)

found a little issue with it here:
currently there is no way for me to access the Jobs directly from here while they are pending, nothing is clickable when there is a problem starting up the jobs.

also i think maybe it should show some error, since i think the jobs are still waiting whereas in reality there was an issue starting them up and they failed.

[ReenigneArcher]

Are you sure those are queued? "Required" checks will always show, even before they are ever queued up (same in both the new and old experience)

[ibraheemsaoud]

idk how to explain it correctly, but the problem was with the job itself, so the whole run was never going to succeeded, as in the picture below.
I had to fix the job then rerun it for them to return a result

[ottlinger]

Commit message vs. description

PR's title or commit message may contain ticket references. By default the new design changes this behaviour to not contain the PR's title into the default commit message, thus breaking any automation that parses the commit message one liner.

Example:
apache/creadur-tentacles@a3a9e0b

I manually added "TENTACLES-20:" as a prefix to the commit message. The old layout used to take the PR's title into account and the resulting commit message contained the prefix that is used to trigger email notifications from the underlying JIRA.

Personally I'd prefer to either use the PR's title and copy it into the description field OR make the description field optional.

[willsmythe]

The default commit message shown in the merge experience when you click Merge (or Enable auto-merge) is generated based on your repo's configuration (see changelog). For example, if merge commit merges are configured to use the PR title and description by default, the PR's title and description should be shown in the "confirm" form and used on the resulting merge commit (if you just click Confirm).

The behavior here should be the same between the new and classic experiences.

When you click Merge does the expected commit message appear in the form? If not, can you double-check your repo settings to confirm the appropriate default commit message format is selected?

[ottlinger]

As the repo is managed by the ASF I'm not sure about its settings, but will check when the next merge arises. Thanks for the context and help.

[ottlinger]

Thanks for pointing me to the settings page - to my mind:

would be a more meaningful default. I'll change all my repos and file an ASF INFRA ticket then :)

[scottsauberlt]

UI seems more choppy and slower than the old one. I click Merge and it hangs for 1-3 seconds. Then the branch hangs around for 1-3 seconds and asks me if I want to delete it even though I have auto-delete head branches on.

[willsmythe]

Thanks for the feedback.

I click Merge and it hangs for 1-3 seconds.

What does it do while it's hanging? Is the button disabled (or look disabled)? Is there a spinner?

Then the branch hangs around for 1-3 seconds and asks me if I want to delete it even though I have auto-delete head branches on.

Does the "delete branch" button appear and then disappear a few seconds later? Or do you have to refresh the page for the button to not appear?

[jrp-enf]

The In Progress check 'Started XXm ago' doesn't update the started time when you look at it. You have to refresh the whole page to get it to update.

[willsmythe]

Thanks. We're tracking this.

[rohitchouhan8]

The overall UI is very slow. Scrolling, clicking, and everything. Sometimes, the page just goes blank as I scroll. It feels like there's like a ton more React renders going on or something.

Not exactly the same as https://github.com/orgs/community/discussions/143787#discussioncomment-12340264 but similar sentiment.

[willsmythe]

Are you seeing slowness in the "merge box" area of the Conversation page? Or other pages, like Files Changed?

[janbrasna]

For some reason, in both the original and the preview experience, a conflict to be resolved is "highlighted" in a way it's basically indistinguishable from the starting state, being grey and casting no color outline to signal a problem that needs attending.

Merge conflict is something that's blocking merging the PR. My instinct is that is not a "grey"-level state, I'd much rather see that color-coded as, say, orange — being an issue that needs resolving, incl. an orange highlight for the whole box to draw attention to it.

(NB: Conflicts happen on PRs over time, usually way after their submission. IIUC right now a human has to open the PR page to check mergability to find out there's a conflict — a much better DX would be if the mergability is checked periodically and in case a conflict arises, the PR author gets a notification their PR needs updating… instead of being told by the reviewer as a first thing they do after trying to review the PR;)…)

[janbrasna]

1. Is the wording correct? (Can the changes be merged cleanly, when there's a conflict?)
   "This branch has conflicts that must be resolved"
   "Changes can be cleanly merged."

2. The monospaced filename has a "click" affordance, showing pointer and a hover state, but clicking it does nothing.
   (Inspecting the element it seems to have been marked up or more precisely styled as an input/label, but it's neither…)

[jsoref]

The gray is indeed not a great choice...

I think part of the problem is that there are a bunch of colors and a bunch of shapes, but neither color nor shape indicates which entity is expected to respond to an item.

In the case of the gray ⚠️, it's the PR author.
In the case of the red ⚠️, it's someone with merge permission to the repository (and the "merge is not an allowed merge method in this repository" message is broken, which is the responsibility of github).

I think in almost all cases, github should be able to know which things are addressable by which audiences and could choose to clearly indicate that. It would help:

• people w/ write permissions to the repository
• people w/ approve permissions for the relevant code (not necessarily the same as the above)
• people w/ write permissions to the pull request (often just people w/ membership in the upstream repository, but sometimes depending on PR settings also people w/ write permission to the destination repository)
• people w/o any of the above who just want to get a sense of which court the ball is in for the pr

---

I complained about the conflicts that must be resolved + changes can be cleanly merged thing in https://github.com/orgs/community/discussions/143787#discussioncomment-12281827

It's definitely a bug.

[chlunde]

It would be nice if the merge box link to the job summary, if one exists. Currently, the only "clickable" action take you directly to a workflow, so job summaries are fairly hidden.

As a workaround, we have to publish the job summary as a comment.

[pavel1269]

When switching a merge type, e.g. from merge to squash, the default commit title changes only after unknown delay. It can easily happen to change the merge strategy and commit with a wrong title. The classic does not have any delay so unaware contributor can easily generate wrong title.

[chensjlv]

I would put successful checks in front of the skipped checks. Most of the time people don't really care about the skipped ones.

[paul0403]

Hi, is it possible to restore the "number of unresolved conversations" tab? The old UI had it and it was very convenient!

[rthrippleton]

Agreed - sometimes, reviewers approve but forget to resolve every single conversation, especially in quite a big long-running PR. This makes it easy to track them down!

[peteyus]

Not all checks are showing in the new view every time. The check in the second screenshot is triggered by a label on the PR and it's not showing up in the new view, but does show on the checks tab as in progress.

[vladaionescu]

It would be good if the checks didn't move around. It's hard to click on them when they keep shifting order.