Re: Question about pull-requests

From: Jeff King <peff@peff.net>
Date: Feb 22, 2016, 21:37 UTC
Message-ID: <20160222213702.GD15595@sigill.intra.peff.net>
In-Reply-To: <CAOh0v-WW=hOXw=uTdzkd3afzXCguBHWdaDShwKE3QKqUCOBTzg@mail.gmail.com>

On Mon, Feb 22, 2016 at 05:24:15PM +0530, Nagaraj Mandya wrote:

Show 13 quoted lines

>   In our GIT repository, all users are restricted from merging to
> master without a pull request. This works well and all developers are
> raising pull requests and merging. However, if there is a merge
> conflict during the merge, we have a problem.
> 
>   We follow the instructions provided by Bitbucket and the final step
> is to push the merged code to master to the "origin" repository.
> However, that steps always fails with the error that pushes can only
> be made with pull requests.
> 
>   How do we work around this problem? We want all pushes to happen
> through merge requests but still allow pull requests with merge
> conflicts to get pushed. Thanks.

The strategy we use at GitHub (for our internal work, I mean, but which we also recommend to other projects on the site) is to back-merge master to the pull request branch and resolve the conflicts there. Then you can push that, and the merge of that result to master will always be trivial (unless somebody updated master in the meantime, of course).

In fact, we use the "protected branches" feature[1] to disallow any non-fast-forward merges of a pull request into the master branch. We do our CI tests on the tip commit of each pull request, and they also must pass to allow merging. So you would not want to do any real merging to bring the PR into master; the merge result hasn't actually been tested!

I don't know offhand whether BitBucket has a similar feature to protected branches, but certainly you can do use the back-merge-and-push trick.

-Peff

[1] https://github.com/blog/2051-protected-branches-and-required-status-checks