Question about pull-requests

Hello,
  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.
--
Regards,
Nagaraj

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

The usual way to solve this is to rebase those commits of the pull requests on the updated master. That allows the one who makes the pull request to solve the issues, and then push the branch again (adding --force-with-lease because you've rewritten history).

This should update the pull request, but now it should be able to be merged without conflicts.

That way, you are not required to merge locally into master and push that.

The merge local option will only work if at least someone has rights to push to master, but that is a bitbucket question, not a git question.

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

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

From your message I’m guessing you are using Bitbucket Server with branch permissions [1]. We’re aware the conflict resolution instructions can not always be followed. Improving these is on our backlog (https://jira.atlassian.com/browse/BSERV-7561) - feel free to watch/vote for that issue.

First, let’s start with the most basic case: a pull request you created is conflicted and can’t be merged. Here, you can apply Jeff King’s solution and back-merge the target branch. Alternatively, you can, of course, rebase the branch too. (Check out https://www.atlassian.com/git/tutorials/merging-vs-rebasing for more info on which option to pick and when).

If you are using cascading merges [2] in Bitbucket Server, there’s a chance of conflicts during the merge-cascade, which will generate “Automatic merge failures”. If this happens, Bitbucket will create a new pull request on your behalf. The same strategy as above can be applied: merge the target branch and resolve the conflicts, or rebase.

[1] https://confluence.atlassian.com/bitbucketserver/using-branch-permissions-776639807.html [2] https://confluence.atlassian.com/bitbucketserver/automatic-branch-merging-776639993.html

- Felix

-- View this message in context: http://git.661346.n2.nabble.com/Question-about-pull-requests-tp7648649p7648733.html Sent from the git mailing list archive at Nabble.com.