Update branch with rebase repository setting

[avaly]

The new update branch feature is great!

But for teams which are only using the rebase functionality, it's not optimal to always have to pick the rebase option from a drop down menu.

It would be ideal if there were a repository level setting to configure which option is the default for that button.

[michaelbeaumont]

It'd be great for it to even just remember the last used option like the "Merge PR" option does.

[filipesperandio]

💯 even better then having a default.

[burz]

The issue I am facing is that even when merge commits are disabled in the repository settings, the update button still defaults to merge commits.

Please change the "update branch" button to either follow the same rules as the overall PR options, or allow it to be configured separately to disallow certain options.

(The "update branch" is a great feature, btw!)

[rmacklin]

I would vote for separate configuration as this would allow for the button to be used even when the project desires "semi-linear" history (where merge commits are allowed to be created when merging a fully-rebased branch into the mainline).

[rmacklin]

This was also requested in a comment on another feature request: #3245 (comment) and that comment currently has more upvotes than this post (so the upvotes here are under-represented)

[ManuelRauber]

That would be an awesome feature, if we choose the strategy to update the branch, just like we do with PR merging.

[rathpc]

Hey @scotttesler, any chance we can get some traction on this please? 🙏

[dimisjim]

doubtful, with all the layoffs circling around.

[marcusramberg]

@krisnova ^^ This is the issue I was talking about on your Twitch stream. 😸

[ferologics]

ditto

[valentin-krasontovitsch]

there's no way for a user (non github employee) to contribute to the github codebase and make this happen, is there?

[deefactorial]

Is there any update from the GitHub team regarding this feature request?

[dcornewell]

We were just discussing how update with rebase is preferred but most of my dev team just clicks the button. I'd like it at least to be configurable to be the first option to save a click.

[GANTR0N]

This would be a major help for how our testing system is integrated, this is a small change that would be a big QoL help.

[williamglasse]

Our team would really benefit from this too! Have had a couple of team members accidentally merge, and then have had to undo that change. Would really like to be able to select a default other than "merge"

[mbirchdk]

Would love this feature! Sucks when teammembers accidentally presses the merge button

Personally I want merge-commits from feature-branches on to the main-branch, but I dont want to allow merge-commits for updating other branches, this should be done using rebase. I tried enforcing it with the branch-protection rule "require linear history" on all other branches than main. But unfortunately it uses the entire commit-history, and not just the commits on the specific branch

[manemarron]

Our team would love this feature as well. We would like the feature branches to be updated using rebase to avoid having so many merge-commits. Our master, staging, and develop branches would be updated using merges obviousy, but for feature branches or fix branches, this feature would help us have a cleaner commit history in a simpler way.

[codella]

This would be very nice to have 🙏🏽 please, make it happen!

[repsejnworb]

I feel like over the years we've added thousands upon thousands of votes for this feature, but for the sake of it - here is my vote added (again).

[pieeri]

Adding our voice here as a very nice way and feature for enforcing such a development process at an organisation level!

[ankon]

Our workflow is to "rebase" branches in PRs, so that the history in the branch itself stays quite linear, and then create explicit merge commits (without squashing) when the PR branch gets merged into the mainline.

It would be very helpful for us indeed if we could org-wide require the "Update branch" button to always use "rebase" as strategy.

[csi-lund]

org but also repo level configurable as well with the rules as a sub setting of requiring branches to be up to date

[rathpc]

It has been nearly 3 years since this issue was first raised, is there any movement on this at all?

[repsejnworb]

You should see the original original original xD

I've followed isaacs/github#88 (comment) since it's inception, which was the first ask for something similar.

[ptrkstr]

Would love this feature as well 🥹

[gingters]

We would need this too. We want to explicitly FORBID updating the branch with a merge, ONLY rebase should be allowed.

[robertIsaac]

FYI adding a rule that require liner history, automatically disable the merge button and rebase become the only available option

[0cjs]

I wonder if things might be tweaked so we could add a rule that since that the history must be linear since a given commit on a branch.

[sandstrom]

@robertIsaac It isn't only about old repos. Many new repos also want 'semi-linear merge' as the preferred strategy.

[robertIsaac]

@robertIsaac It isn't only about old repos. Many new repos also want 'semi-linear merge' as the preferred strategy.

yeah I understand there can be some different use cases depending on different branching strategy

[csi-lund]

Thanks for raising the above points this is exactly what we need as well.

[dannysauer]

I have "require linear history" in a separate ruleset from the "required PR checks" (for automation purposes), and I get a merge option. The behavior does not change when adding "require linear history" in the same ruleset as the required checks. Does it only work for people using the old branch protection rules?

[alex-haas-bosch]

We would need this too.

[damusnet]

With the new Merge UI, the trick of adding a rule that requires a linear history, to automatically disable the merge button, and having rebase become the only available option, does not seem to work anymore. Worse, it appears that the Rebase option is not available at all anymore, as the dropdown is completely gone.

Edit: mmmh, maybe something else is happening, because if you remove the requirement for linear history, the dropdown comes back. Feels like a bug somewhere.

[uaqben]

[kragoth]

And now the work around doesn't seem to work for me anymore. sigh
My team now have to rebase our PRs locally and force push. There's no way for me to do it via the PR screen at all now.

Edit: nevermind, I got the workaround working again.

[aaron-riact]

My current work around is to let devs do whatever they want on branches, but require that PRs themselves are up to date and enforce that they have no merges in a github action. Perhaps there is a better way of achieving this?

      - name: Check out this repo
        uses: actions/checkout@v4
        with:
          path: repo
          fetch-depth: 0

      - name: Ensure PR has linear history
        if: github.event_name == 'pull_request'
        working-directory: ./repo
        run: >
          if [[ -n $(git rev-list origin/$GITHUB_BASE_REF..origin/$GITHUB_HEAD_REF --merges) ]]; then
            echo "::error::PR contains merges"
            exit 1
          fi

[fgmehlin]

For bigger teams it can get pretty messy if we start updating with both rebasing and merging. Teams usually stick to one option only, so that seems to be pretty much a must have.

Gitlab offers this for a long time already. I sincerely hope this is added very soon.

Here's another strong vote for this.

[davsv]

I'd like a feature that DISABLES the "Update with rebase" and ONLY uses "Update with merge commit". I have disabled deletion and force pushing for all branches but the "Update with rebase" still shows up.

[dannysauer]

Because rebase works by replaying commits, you lose the original signatures doing a rebase on GitHub. I suppose that's a negative.

[ptrkstr]

This has piqued my curiosity; what goes wrong when someone updates their development branch with a rebase rather than a merge?

@0cjs GitHub recreates the commits meaning they have different commit hashes

[0cjs]

So those reasons make sense to me for merges of dev branches into main but here we're talking about the other direction: updating a dev branch with new commits from main. What's the advantage of preserving commits on a dev branch? (The disadvantage seems obvious; if after review you fix a mistake, you end up preserving the mistake and the fix on main, rather than, when you merge to main, having just the correct version there. The same goes for, e.g., a rename from a new refactoring on main: if someone renames a to b, your newly generated commits from a rebase are all using b from the start, rather than using a and then having a merge commit that changes the as to bs.)

[dannysauer]

@0cjs the op just said branches, not developer branches. ;) There are development strategies which aren't trunk based, where more branches than Main are either long lived or otherwise aren't individual developer working spaces. :)

This is also primarily talking about the "update Branch with rebase" button on GitHub, not telling people to avoid rebasing locally. Though preventing force pushes would also block local rebases. 🤷‍♂️ I can definitely imagine a world where blanket policy would be to never rewrite history. For example, I have a gitops IaC repository where the content is mostly automatically generated; "developers" are usually programs and I actually need to record all history for change management / compliance / audit purposes.

For what it's worth, I don't disagree. Just listing some other scenarios. :)

[0cjs]

@dannysauer No, the OP was talking specifically about the "Update with rebase" and "Update with merge commit" buttons, which update a dev branch from the main branch. And note that in his case developers cannot rebase locally either, or to be more precise, they could do that but they can't push up those changes because he's disabled force pushing for all branches.

And I am familiar with using Git for compliance, etc., with automatically generated content; this just doesn't sound like that kind of situation at all.

FWIW, I do agree that being able to use the "Update with rebase" button on branches that are not allowed to be force-pushed is probably wrong behaviour, regardless of the reasons someone disabled force-push.

[allisonphillips]

I've sacrificed my Friday night to figure out all the things...

Repository Settings

• Check Allow rebase merging and Always suggest updating pull request branches
  

Rulesets

Go to Rules → Rulesets

Create a branch ruleset

Target ALL branches

Check the box for Require linear history

Save & Activate it

Exported Rule

If you export your saved rule, it should look something like this:

{
  "name": "Linear History - Rebase",
  "target": "branch",
  "source_type": "Repository",
  "enforcement": "active",
  "conditions": {
    "ref_name": {
      "include": [
        "~ALL"
      ]
    }
  },
  "rules": [
    {
      "type": "required_linear_history"
    }
  ],
  "bypass_actors": []
}

PR Experience

When a branch is out of date, it will show a single rebase button to resync the branch:

If it cannot be rebased, it will list the files that need merge conflict resolutions.

---

🤬 I enabled the linear branch history rule and now I can't push new expletive branches 👇🏾

If your default branch's history is non-linear, the branch rule will prevent you from pushing a new branch (even if your new commits are linear and you are rebased on master).

Today's the day to rename master to main!

• Create your new branch off of the old default branch, rebase --root, and push it up:

  git checkout -b main origin/master
  git rebase --root
  git push origin head
  

  Sure, you could just rebase --root master and force push it up, but let's assume you are like me in being both risk-averse and want to err on the side of being meticulous for the purposes of compliance audits and general continued employment.

• Confirm that you correctly duplicated master:
  http://github.com/$ORGANIZATION/$REPO/compare/main..master
  

• Switch your default branch in the repository settings (there's an ⇔-ish icon to the right of the branch name, that will let you switch to a different default branch)

  • Update your branch protection rule to exclude master-non-linear-archive (or it will prevent you from renaming master)
  • Go into your repository's branches and rename master to master-non-linear-archive
  • Create a legacy branch protection rule to lock the branch

• Change the tracking branch on existing PRs to main (edit the PR description and it will let you switch the branch), rebase each branch on origin/main and force push back to origin (or make your team do it if you are some sort of cruel overlord)

• Update any workflows or other docu that might reference your old default branch name.

• Set head locally:

  git branch -u origin/main main
  git remote set-head origin -a
  

😌

[0cjs]

Can you add an image of the new drop-down you now get?

[allisonphillips]

Can you add an image of the new drop-down you now get?

It's just a button, but I added it.

I also ran into another fun new problem, so there is a new section for 🤬 I enabled the linear branch history rule and now I can't push new expletive branches 👇🏾

[gcv-epalmer]

Thank you for your service 🙏

[vtjballeng]

mal to always have to pick the rebase option from a drop down menu.

It would be ideal if there were a repository level setting to configure which option is the default for that button.

Same here! We want a way to lock out the default update branch merge commit behavior in favor of rebase.

[roger-watkins]

I would love a way to just disable this button as both merge and rebase in the UI wrecks our PRs.

• Merge update prevents PR merging due to linear-history (which I really, really want to keep)
• Rebase update wrecks commit signing.

Given that both options are useless for us why can I not just turn it off (Always suggest updating pull request branches - does nothing).