Rebase functionality for "Update branch" button

[trivikr]

Is your feature request related to a problem? Please describe.
Right now, GitHub shows "Update branch" button when the base branch is outdated.

On clicking "Update branch", it creates a merge commit for the PR which merges default branch into PR branch.

It would be nice if this had a "rebase" option, rather than creating a merge commit

Describe the solution you'd like
A "rebase" option to update PR branch, which can be configured in Update branch button settings which allows choosing between merge and rebase.

This could be similar to existing "Merge button" settings.

Describe alternatives you've considered

• Stick with the merge commits created by existing "Update branch" button behavior.
• Rebasing from the workspace instead of using "Update branch" button.

Additional context
Prior discussion in isaacs/github#1113 (comment)

[evi-liu]

This space is currently reserved for feedback on Discussions and GitHub for Mobile. This is noted in our README and the pinned discussion.

All other feedback at this time can be shared through our support channel or our community forum.

[dimisjim]

It seems the button was removed altogether today.

Any news regarding that?

[AndreasPB]

This is the biggest thing that I miss after moving from GitLab. The require branches to be up to date with a merge button is so messy and confusing for collaborators if the project wants to work with a semi-linear strategy.
I'd love to be able to rebase with the button, or just remove it, so people aren't baited into messing up the git history

[ljharb]

I am SO EXCITED this landed https://github.blog/changelog/2022-02-03-more-ways-to-keep-your-pull-request-branch-up-to-date/ - but, is there some way i can disable "update branch" while keeping "rebase branch"? Nobody ever wants a merge commit inside a pull request :-)

[rmacklin]

I'm not sure if upvoting @ljharb's reply to this post is as likely to get attention on the feature request as upvoting a new/separate post.

There is such a feature request post here: #12032 so I would encourage folks who want this feature to upvote that as well.

[rtrad89]

I would rather want to disable the rebase option and keep the merge commit, because I don't want all signed commits to be unverified.

[marioslazaro]

❤️

[jkester1986]

would really love for it to be configurable so we can choose which option we want, or at the very least which option to default to. My team uses the rebase strategy, and I'd love to use this feature for branch protection, but I don't want to add it on while the default is only ever merging

[valentinsa]

Estoy MUY EMOCIONADO de que este https://github.blog/changelog/2022-02-03-more-ways-to-keep-your-pull-request-branch-up-to-date/ aterrice, pero, ¿hay alguna manera de deshabilitar "actualizar rama" mientras mantengo "rebase rama"? Nadie quiere una confirmación de fusión dentro de una solicitud de incorporación de cambios :-)

[kenhuang]

is there a way to disable Update with rebase? as auto rebase via GH would not work with signed commit.
we would like to only keep Update with merge commit option, this will allow squash commit PR to preserve approval status.

🙏

[ljharb]

If a squashmerge can keep the signing, why wouldn't a rebase keep it? They're both different SHAs.

[Thaina]

If a squashmerge can keep the signing, why wouldn't a rebase keep it? They're both different SHAs.

Maybe because squashmerge remove all signing to be yours sign only while rebase use other people signing?

[ManuelRauber]

is there a way to disable Update with rebase? as auto rebase via GH would not work with signed commit. we would like to only keep Update with merge commit option, this will allow squash commit PR to preserve approval status.

🙏

Best would be to have the options selectable by the maintainers, just like we can do it with PR merge strategies

[rtrad89]

is there a way to disable Update with rebase? as auto rebase via GH would not work with signed commit. we would like to only keep Update with merge commit option, this will allow squash commit PR to preserve approval status.
🙏

Best would be to have the options selectable by the maintainers, just like we can do it with PR merge strategies

I can disable the rebase option when merging a PR, but not when updating a branch. I think it makes sense to disable rebasing everywhere due to the signed commits issue.

[Pr0methean]

Maybe because squashmerge remove all signing to be yours sign only while rebase use other people signing?

Why not sign the merge/rebase commits with GitHub's own key when it's done through the web UI and the sources are all verified?

[maxwu]

Cheers for the feature. One question is how to choose email while clicking "update branch"? I have different emails for organizations and personal use.

[codebydant]

Hi guys, is there a way to restrict only rebase button? Because if a new contributor does not press the arrow option to select rebase button it will automatically run the "update branch" with the merge functionality.

[mickael-h]

I see this is still being asked, so I'll join the bandwagon. Please let us restrict to only rebase... Or at least propose rebasing by default...

[mohamed-haidara-ai71]

I am joining the bandwagon as well. But since this discussion is answered. Not sure if someone from GH will take a look at this

[coldfire22x]

+1

[erikacarvalho]

➕1️⃣ this is as necessary as being able to set the PR merge strategy @github

[zkiezun]

+1, that would be great to have it!

[hsuabina]

I see this conversation started to support an 'Update branch' with an update by rebase option, which is nowadays available. This conversation is considered answered.

I found this other recent conversation (still unanswered) which is specific to allow configuring the possible/default options for the 'Update branch' button, which is what a lot of people in this thread is wishing for.
https://github.com/orgs/community/discussions/57002

[AndrewEastwood]

Is there any way to set the default op to be "rebase" rather than just "update" ?

[fabiendem]

For those looking for a rebase by default when we hit the Update branch button:

You can go to the Branch protection settings of your repo, create a rule targeting your feature branches (or the ones in which you don't want to see a merge), and enforce the Linear history.

You will then get the following:

I would bear in mind that your contributors will have to adapt and only use a rebase to update with the main branch locally, which can be a big move for some folks used to the merge.

[ljharb]

Unfortunately this doesn't work when you disable rebasemerge and squashmerge (which are not the same as rebase + merge and squash + merge, sadly), so this isn't sufficient.

I should be able to disable the "update with merge commit" button regardless of how I've configured the available merge strategies.

[prenaux]

That option is broken, if you click "Update branch" (without going through the drop down that shows when you press the arrow) it will create a merge commit even though the "Update with merge commit" is greyed out in the drop down....

[ryukinix]

What a mess. I'm very disappointed. GitLab has been doing this well for years.

[nbolton]

The solution by @fabiendem works, but I'd like to rephrase for the benefit of others, as I missed the point of his comment (that you need a ruleset that specifically tagets the PR branches).

The trick is to have a ruleset for master (include default) and a separate rulset for everything else (all branches excluding default) which forces linear history. That way, the merge button gets disabled and it defaults to rebase.

---

Edit: Somehow the following trick of enforcing linear history on non-master/main has stopped working for me, which is frustrating.

[nbolton]

so for projects which allow PRs only from own feature branches it should work as expected, right?

Yeah, if your project does not allow external PRs (i.e. is a private repo) then you should never see a "merge" button; only "rebase".

[rmacklin]

Note that there is still this big limitation: https://github.com/orgs/community/discussions/3245#discussioncomment-7343652

this doesn't work when you disable rebasemerge and squashmerge (which are not the same as rebase + merge and squash + merge, sadly), so this isn't sufficient.

I should be able to disable the "update with merge commit" button regardless of how I've configured the available merge strategies.

For those who want PRs (which themselves have a linear history) to only be merged via a merge commit (git merge --no-ff), they disable the squash and rebase strategies which currently prevents them from checking "require linear history" in any rule. So there's still no way for those repositories to only have the "update with rebase" option on PRs.

[nbolton]

Update: This has stopped working for me, frustratingly. I updated my OP to reflect.

[kragoth]

Update: This has stopped working for me, frustratingly. I updated my OP to reflect.

Yep, this has been broken recently. I don't even get the warning message that merge commits are not allowed anymore.... sigh

[sithlord48]

This just broke on our repo, the update button has returned without any repo setting changes.

[pdobb-n2]

I'm seeing this / a similar issue where: Toggling on "Require linear history" for a feature branch directly takes away the option to "Update with rebase" from the "Update branch" drop-down in a PR, leaving only "Update" (which does an "Update with merge commit"). This is backwards since one cannot create Merge commits when "Require linear history" is on.

[cknd]

I'm seeing this / a similar issue where: Toggling on "Require linear history" for a feature branch directly takes away the option to "Update with rebase" from the "Update branch" drop-down in a PR, leaving only "Update" (which does an "Update with merge commit"). This is backwards since one cannot create Merge commits when "Require linear history" is on.

this is still broken, right? a year later

[nbolton]

Anyone else always see "Update branch" the first time a PR page loads, then on refresh it says "Rebase branch" instead?

If so, please vote:

• Bug: "Rebase branch" only shows only after refresh #191285

First load:

After refresh: