2

I need to approve pull requests for a development we are doing. It's a distributed team scattered over the planet but it's a private (company) project.

I've had two times now that I needed to resolve a merge. The docs at bitbucket, where we are hosting the repo, say:

To resolve these kinds of conflicts you pull the changes to your local repository and resolve them there.

But what is the correct procedure?

  • Pull the developer's pull request locally, fix the issue, and then push it back to origin
  • Check out the destination (development) locally, merge there and do not care about the branch originating the PR?

The first fixes the problem completely, as our remote developer needs to update his own branch afterwards - but feels a bit "intrusive", as I am changing his own personal feature branch.

The latter feels right, but doesn't completely fix the issue. If the remote developer is not diligent enough, he may still drag the conflict into the next PR.

The third of course is to reject the PR altogether, which is the cleanest probably, and have the remote dev fix the issue. He may not always be able to do so though, that's why I am in charge of approving...Also this is slow, and may require a day of delay due to time zone differences.

transient_loop
  • 5,984
  • 15
  • 58
  • 117
  • 1
    Possible duplicate of [How to resolve merge conflicts in Git?](http://stackoverflow.com/questions/161813/how-to-resolve-merge-conflicts-in-git) – Eli Sadoff Nov 05 '16 at 14:15
  • This may be verging on opinion based, but it seems to me option 3 is preferred, then in consideration of time and priorities go with option 1 which basically does their work for them. You might want to look into continuous integration options like Travis-ci that aim to prevent these situations in the first place. – Jeff Puckett Nov 05 '16 at 16:54
  • @EliSadoff it's not a duplicate IMHO, that question only relates to how to resolve merge conflicts in general – transient_loop Nov 05 '16 at 17:13
  • @JeffPuckettII thanks that all sounds about right. I agree it could vere to opinion-based, but hope you'll grant that the question is not about "what is the best tool for X", but a real-world programming problem. We do use Codeship for CI, how can that prevent this situations really? A developer still needs to issue pull requests, and how can CI avoid conflicts? – transient_loop Nov 05 '16 at 17:19
  • @JeffPuckettII if you care you may put your comment as a response, and I will accept it. – transient_loop Nov 05 '16 at 17:35
  • I would definitely lean towards the third- if you make it a matter of policy that developers have to merge in the development branch and resolve conflicts themselves before submitting the pull request the time zone difference shouldn't be too much of a problem. – Chris Nov 05 '16 at 18:16

1 Answers1

1

this is how we do it in our organisation. whoever creates the pull request is responsible for resolving the conflicts. as he knows the best about the changes he has done, he is best suited to resolved any conflicts. Also in this way all the responsibility does not go to one person. However you can still be the person to just click the merge button once all the conflicts are resolved and other people have reviewed the PR.

root
  • 3,517
  • 2
  • 19
  • 25