"Update branch" button for author of PR

[probonopd]

If the author of a PR wants to incorporate the latest changes that have been made in master since the PR has been submitted, it is currently cumbersome and only possible on the terminal for the author of the PR to update the PR to incorporate the changes:

git clone https://github.com/me/project -b feature/foo
cd project
git pull https://github.com/upstream/project/ master
git push

This button should be available to the author of the PR (it is available to the owner of the repository):

cc @TheAssassin

[mike-marcacci]

This is already the case for me (as a PR author to a repo I don't own). After I clicked the button:

[fruch]

if the PR is from a fork, this should work

[gabrielgrant]

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

[rsp]

@gabrielgrant Yes. Or at least I should be able to disable the button if I prefer rebasing instead of merge commits to keep the PR branch up to date. Right now I have to tell people to never press the button but they still do occasionally.

[acjh]

@rsp You can already do that in the Settings page.

[rsp]

@acjh Could you please let me know which option is that?

Note that we are talking about the "Update branch" button:

Not about the "Merge" button for which there are those options in the Settings:

[acjh]

@rsp I was mistaken.

[marekciupak]

Big +1 for "rebase" option or option to disable the button.

[andreineculau]

Up to this date there are 5 major git flows

1. "don't care" or "I do whatever a stranger tell me to"
2. merge all the way or "I will never ever rebase, I don't even know the word"
3. only merge PRs/topic-branches i.e. you never merge master into a topic branch, but instead you would rebase the topic branch onto master, if you wanted to update it
4. enforce PRs/topic-branches to be up-to-date with master and create merge commit when merging them
5. rebase all the way (and fast-forward)

I fall in the 3 or 4 box. 4 if there's a system that does notify/rebase automatically for me, and 3 where in most cases I try to keep my topic branch up-to-date, but I won't fret if it's not.

Why? Because I know that this is what

• keeps surprises away i.e. your topic branch is fine, but new commits in master will break it, but you'll never know until you merge it into master
• simple, sane and good-looking reverts of merge commits
• easiest for git hooks to do checks
• easiest on the eye when looking at a git graph - see http://www.memonic.com/user/pneff/folder/version-control/id/1QbN
• easiest to debug a git history (not the visual graph) but when going through a git log

For some unknown reason to me Github is doing anything but trying to help me keep a clean history, no matter what, and this "Update branch" (which I can only assume that everyone, even merge lovers, assume that it is equivalent to rebase PR on top of destination branch) makes no exception.

What I see beneficial to everyone is

• "Update branch" button should be configured in the repo Settings if it's
  • a git merge master
  • and/or git rebase master
• "Merge button" should be configured to
  • "Allow merge commits"
  • "Allow squash merging"
  • "Allow rebase merging"
  • "Allow rebase merging (no-ff)"
  • "Allow update branch, run checks and merge" <----- THIS! Nobody wants to wait for machines to do their job, print "ALL OK!" and then you can press yet another button, to trigger some more machines, etc. If the repo owner wants the PR to be up-to-date, and reviewers accepted the change, just update the branch, run the checks again, and if they are green, just merge.

I really don't want to sound negative, but I don't understand how such a simple but core thing to git work has been overlooked and left to hacks (neat nevertheless) like https://github.com/tibdex/autorebase .

PS: sorry for the wall of text

[iensu]

Please just add an option to disable the Update branch button. It is extremely hard to get everyone in the team to follow the 3+4 flow described by @andreineculau when the update button is so easily accessible.

[Thaina]

Could we also have squash branch functionality?

All of the nitpicky repo crave for people to squash their pull request even they could squash on merge. So the squash and merge just become useless feature. I need to squash my branch just for fixing 2 files or else they will not welcome the fix of their bug

[mebibou]

Instead of disabling the Update branch button, maybe when we select only Allow rebase merging policy, we could have a Rebase branch with master button? one that will do the rebase without merging the branch, because otherwise the only way to do this is use the command line to do git checkout <branch> && git rebase master && git push -f
Or maybe every Policy adds a different update button (multiple choices):

• Allow merge commits => Update branch
• Allow rebase merging => Rebase branch

[gabrielgrant]

@andreineculau fwiw, gitlab makes it simple to do exactly what you're asking for: when a PR (or Merge Request, in GitLab parlance) is out of date, it shows that "rebase" button that is still sorely-missing from GitHub's UI

(Since I requested that a couple years ago above; it has become by far my most popular ever comment on github :P )

After hitting rebase, GitLab immediately shows that auto-merge-after-checks-pass that you're asking for:

So takes two clicks (with no waiting in between) rather than the one that you asked for, but I'll take it :) These together are two of several reasons i've moved most of my serious private projects over to GitLab

[andrzejnovak]

bump

[SkySchulz]

We very much need Update Branch to respect our repo's rebase option and not merge master into the PR, but, instead rebase master` onto the PR.

I cannot count the number of times we have had to un-tangle the mess this creates in our PRs.

[sefasenturk95]

+1 on this one.

[Callisto13]

+1

[trivikr]

GitHub now accepts public feedback in https://github.com/github/feedback#github-public-feedback-discussions

I've created a Discussion for the rebase functionality at community/community#3245