Re: Protecting master branch on GitHub?
Peter Cock <[email protected]> Thu, 24 Aug 2017 11:34:40 +0100
| Newsgroups | gmane.comp.python.bio.devel |
|---|---|
| Message-ID | <CAKVJ-_5M85qQ-dCD3vtuPs9QSyEJubsNvX8L_bNj0u7Gxtw8tA@mail.gmail.com> |
On Wed, Nov 11, 2015 at 5:19 PM, Peter Cock <[email protected]> wrote: > On Fri, Sep 4, 2015 at 11:20 AM, Peter Cock <[email protected]> wrote: >> On Fri, Sep 4, 2015 at 10:07 AM, Christian Brueffer >> <[email protected]> wrote: >>> On 2015-09-04 11:02, Peter Cock wrote: >>>> >>>> Hi all, >>>> >>>> GitHub have rolled out some interesting new functionality: >>>> https://github.com/blog/2051-protected-branches-and-required-status-checks >>>> >>>> The ability to protect the main branch should prevent any accidental >>>> rewriting of the history (from a forced push), which would cause >>>> widespread inconvenience now we have so many forks. I'd like to >>>> enable this if no one objects. We turned this on in November 2015. >>>> The second new feature would disable the web-GUI merge button >>>> until our TravisCI tests have passed. I usually do the merges at >>>> the command line anyway (sometimes rebasing, often to add a >>>> note to the NEWS and CONTRIB files), but again these seems like >>>> a sensible precaution? What do people think? > > ... > > Right now I have not enabled this higher level of protection, the > text for which reads: > > "Require status checks to pass before merging. > 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." Many times we as a group have broken the builds on the master branch (TravisCI and/or AppVeyor tests were failing). This can cause work for each other, but worse it causes false-positives for testing pull requests which may deter new contributors. If anyone can push directly to the master branch this is all too easy to do, even a "harmless" edit can sometimes surprise us (e.g. fails a style check, or impacts a doctest), and I'm guilty of this too. How do people feel about changing our policy to say changes should all happen via pull requests (and take advantage of the GitHub settings to enforce this)? Peter