Satish Balay <[email protected]> writes: > On Thu, 4 Sep 2014, Jed Brown wrote: > >> We have way bigger problems if people are skipping (1). Branches need >> to be reviewed before merging. > > This reminds me - is there a way to disable 'merge' button on the pull > request page? That basically skips the whole workflow..
Not really, but GitHub suggests using their API to run a "test server" that advises against clicking the merge button. > My view is - pull request workflow is same as feature-branch workflow > with one of the itegrators takes ownership for it. [how does one take > ownership?] > > - create a local branch for the pull request. > - merge it to next for testing > - when satisfied - merge to master [or maint - whichever is appropriate] > > The 'merge' button on the pull request looks attractive. > - lets us skips creating a local branch for it > - lets us skip merging locally and rely on merging remotely. > > But this skips the whole workflow of testing.. Yeah some of > us are recommeding a pull request to 'next' - but I think thats > still broken. [it shortcuts the merge to next - but one still > has to create a local branch to merge to master]. > > And I suspect this is seen as encouraging feature branchs should start > off next.. > > So I think its best to remove the 'merge' button [if we can]. And > never use it. And not recommend pull request to 'next'. They should > only be to 'master' or 'maint' [bitbucket should not even offer any > other branch for a pull request..] Sounds fine to me, but bitbucket doesn't offer such fine-grained policy enforcement.
pgp3GEXgdN2Uv.pgp
Description: PGP signature
