-
Notifications
You must be signed in to change notification settings - Fork 236
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Requiring status checks before merging #1783
Comments
Yes, I keep mistakenly merging into "master", as it is natural for users to direct pull requests there. It would be great if I could do that only after being presented with a vivid warning, for any branch that is not "development". |
Checks can now be triggered for any branch from this page: We can remove pre-master now. |
I've been waiting for that magic button to suddenly appear for a week now. Thanks! |
You hadn't merged into master till recently, I believe. |
I've just figured out a potentially better way: click a button to submit a pull request from development to master. As in #1862 |
@DanGrayson @mikestillman you may have seen the following tip from GitHub: |
Updating for new features: GitHub's branch protection settings have quite a few options that would work well for us:
In addition, GitHub CODEOWNERS files tell it who "owns" a piece of code and should submit a review before it is merged. I'm not sure if we necessarily need this, but it's an option. |
Github allows for restricting merges to certain branches in various ways:
This is all documented here: https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/defining-the-mergeability-of-pull-requests
We should institute similar restrictions to prevent accidentally merging PR's with failing tests into incorrect branches, as happened today with #1778.
To make matters worse, after that PR was merged into master, master was merged into release-1.17, then release-1.17 was merged into development and pre-master. This is excessive and confusing, and has lead to all four active branches to be in a failing state!
Moreover, now that there's a fix (#1782), even fixing it will leads to a spaghetti of merges between these 4 branches, because we have to do 4 merges to fix all the branches! I think we should also reduce the number of parallel active branches to only master and development. As I explained in #1691 (comment):
The text was updated successfully, but these errors were encountered: