You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've figured out where GitHub was hiding the option to require a review before merging changes. Turns out it was under "Branches" since these settings are per-branch.
So, now the master branch of rs-tiled is protected, with changes always requiring a pull request with at least one approval, which also passes the "build" check that we've set up (which checks compile and runs tests). I hope it won't get in the way. :-)
Another thing I'd like to suggest, is to prefer squashing pull requests when merging. This keeps the history of the branch much more readable. Merging without squashing will remain possible, but should only be used when there are multiple separate commits that we'd prefer to keep separate.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I've figured out where GitHub was hiding the option to require a review before merging changes. Turns out it was under "Branches" since these settings are per-branch.
So, now the
master
branch ofrs-tiled
is protected, with changes always requiring a pull request with at least one approval, which also passes the "build" check that we've set up (which checks compile and runs tests). I hope it won't get in the way. :-)Another thing I'd like to suggest, is to prefer squashing pull requests when merging. This keeps the history of the branch much more readable. Merging without squashing will remain possible, but should only be used when there are multiple separate commits that we'd prefer to keep separate.
Beta Was this translation helpful? Give feedback.
All reactions