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.

[matte1]

Second! This is definitely a pain point for our team!

[Digirik]

Wishing for this aswell!

[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-cko]

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

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

[jkester1986]

thanks!

[nbolton]

FWIW, I've noticed that some PRs (maybe older PRs before changing the rulesets) still have the old button behavior. Haven't figured out why yet.

Edit: Ah, I think I figured out why. Branch protection rules (e.g. linear history) can only apply to your branches in your repo, i.e. not PRs from external branches. So if you're an open source project accepting PRs from contributor forks, then you'll still see the merge button as you have no control over external repos and their branches.

[turboBasic]

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

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