You can allow rebase merging [1] while disabling other PR options, and require linear commit history [2] if desired.

[1]: https://docs.github.com/en/free-pro-team@latest/github/admin...

[2]: https://docs.github.com/en/free-pro-team@latest/github/admin...

Thanks, but I don't think that is quite what I want. What I mean by "cactus" history is that the feature branches have a linear history that starts at the tip of the master branch but when we merge them back into master we still use a merge commit. Looks like this:

      o-o-o   o-o-o   o-o
     /     \ /     \ /   \
    o-------o-------o-----o

We like doing that because, as the grandparent poster said, it clearly delineates the point where each PR was merged. AFAIK, the Gihub option to require a linear history assumes that you would want to flatten all the commits without any merge commits at all:

    o-o-o--o-o-o--o-o

I don't know a way to enforce this, but what may help is knowing that by default, you can push into the PR branch even if it is from someone else's fork: https://docs.github.com/en/free-pro-team@latest/github/colla...

I always go into each new repo I create and turn off the ability to merge and require commits to be up to date with master, I think this might get what you want?

Do you know can I enforce that a PR must be up to date with master before it can be merged? I don't remember seeing that option in the branch protection settings.

"Require branches to be up to date before merging" is a check box under branch protection rules, I always turn it it. It's under the required status checks section.

Thanks! Turns out that this setting is hidden unless you first check the "Require status checks" option.

Oh good to know! I forgot it's hidden until that section is enabled. Does feel like a feature that should be top level, OSIT!