[bug] GitHub Android app: "Update branch (Rebase)" creates a merge commit instead of rebasing

[ricog]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Android

Body

On the GitHub Android mobile app, selecting Update branch (Rebase) in
the Update branch options sheet and confirming the action produces a
merge commit on the PR branch — identical to what plain Update
branch (merge) does. No rebase or force-push occurs.

The same action performed from the web UI on the same PR works
correctly (rebases the head commit onto main and force-pushes).

Repro repo (public, minimal)

• Repo: https://github.com/ricog/gh-mobile-rebase-bug-repro
• PR: Repro: mobile app Update branch (Rebase) produces a merge commit ricog/gh-mobile-rebase-bug-repro#1

The PR is deliberately the simplest possible case for an Update branch
(Rebase) action:

• feature/example has one commit (adds feature-B.md)
• main is exactly one commit ahead (adds feature-A.md, untouched
  by the feature branch)
• The two changes do not overlap — rebase is trivially conflict-free
• Repo settings: allow_rebase_merge=true, allow_update_branch=true,
  allow_merge_commit=true, allow_squash_merge=true

Repro steps

1. Open the above PR in the GitHub Android app.
2. Tap Update branch.
3. Open the Update branch options sheet.
4. Select Update branch (Rebase) and confirm.
5. Inspect the resulting head commit.

Expected

A single new commit on feature/example whose parent is the current
main tip. A HeadRefForcePushedEvent recorded on the PR timeline
(since rebase rewrites history).

Observed

A merge commit with two parents and message
Merge branch 'main' into feature/example is added on top of the
existing head. No HeadRefForcePushedEvent is recorded — confirming
that no rebase + force-push pipeline ran.

Evidence from this PR (left in the broken post-action state)

Item	Value
Original feature/example head	106e378e5e9534ca6a66cc286c7ee99410a936f6 (single commit, parent = 87d27a56)
main tip	ad47f80f11ad4d7c5eea06222e18570a189bcb09
Head after mobile Update branch (Rebase)	df0bd7777b903c9d19333cff31444217c2147dae
Resulting head's parents	[106e378e…, ad47f80f…] (two parents — merge commit)
Resulting head's message	Merge branch 'main' into feature/example
Force-push events on the PR timeline	none

Cross-check via API:

$ gh api graphql -f query='{
    repository(owner: "ricog", name: "gh-mobile-rebase-bug-repro") {
      pullRequest(number: 1) {
        commits(last: 1) { nodes { commit {
          oid messageHeadline parents(first: 5) { nodes { oid } }
        } } }
        timelineItems(first: 10, itemTypes: [HEAD_REF_FORCE_PUSHED_EVENT]) {
          nodes { ... on HeadRefForcePushedEvent { createdAt } }
        }
      }
    }
  }'

shows the merge-commit head and an empty timelineItems list.

Web UI comparison (works correctly)

Performing Update with rebase from the web UI on a separate PR
(same repo settings, same shape of one-commit-ahead/one-behind PR)
correctly replays the head commit onto main, leaves a single commit
on the branch, and emits a HeadRefForcePushedEvent. So this is
specifically a mobile-path bug, not a per-repo configuration issue.

Environment

• GitHub for Android, version: 1.264.1 (933) (installed from Google Play Store)
• Device: Pixel 10 Pro Fold
• OS: Android 16 (build CP1A.260505.005, security patch 2026-05-05)
• Account: ricog (PR author and actor of the action)

Related

• discussion Allow branch update with rebase in mobile app #17542 — "Allow branch update with rebase in mobile app" —
  the rebase update option was originally absent on mobile and is
  evidently being rolled out; this report describes the implementation
  on Android once the option is exposed.
• discussion PR UI update branch with rebase broken on conflict-free branches #188709 — separately reports rebase failures in the web
  UI; not the same path as this report.

Additional notes

• The repo has allow_update_branch=true; with it disabled, the mobile
  app does not surface the Update branch widget at all on this PR
  (regardless of the underlying behind_by=1 state). That may be a
  related UX issue but is not the focus of this report.
• The repo and PR will be left in place after filing so the broken head
  state can be inspected directly. The PR #1 has reset instructions
  for re-reproducing.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐