Protected branches

[dcousens]

@feross any chance we could protect master such that PRs are still the norm?
I'd rather not keep up with the commit log directly if possible.

[rstacruz]

Protected branches won't prevent people from directly committing to master, only push --forces.

[dcousens]

@rstacruz true, for some reason I mis-interpreted:

Choose which status checks must pass before branches can be merged into master. When enabled, commits must first be pushed to another branch, then merged or pushed directly to master after status checks have passed.

To mean that you can only merge, with no direct commits, to master.
Well that sucks.

edit: as pointed out below, it does enforce the behaviour I want, provided you have required status checks.

[Flet]

Its probably still a good idea turn on protection to disallow push --force :)

[feross]

Enabled it:

[Flet]

Ah, so the status checks option is close to what @dcousens was asking for? If I'm reading it right, then it means everything must be pushed to a separate branch first to allow checks to run...

[feross]

Yep, seems that this does what @dcousens wants.

remote: error: GH006: Protected branch update failed for refs/heads/master.
remote: error: Required status check "continuous-integration/travis-ci" is expected
To git@github.com:feross/standard.git
 ! [remote rejected] master -> master (protected branch hook declined)
error: failed to push some refs to 'git@github.com:feross/standard.git'

Happy to try it out for a while. I like the idea that it increases visibility of changes by making it impossible to sneak in commits without people getting email notifications.

[rstacruz]

👍

[Flet]

Yeah, lets try it!

[dcousens]

@rstacruz right, so it seems that specific option allows you to push to master unless you have status checks.
That aligns with my initial impression, it was just that I've thus far only used this feature with status checks. My quick trial to test the above was without status checks, and therefore confused me.

[dcousens]

@feross for it to align with your idea that those with access are still free to make changes, it just means they can self-merge.
Its still a win for visibility.

[feross]

Yep, definite win for visibility.
On Mon, Sep 21, 2015 at 6:32 PM Daniel Cousens notifications@github.com
wrote:

@feross https://github.com/feross for it to align with your idea that
those with access are still free to make changes, it just means they can
self-merge.
Its still a win for visibility.

—
Reply to this email directly or view it on GitHub
#267 (comment).