How to update pull-requesting site after pull request has been merged?

Question

Let's say that GitHub repo B sends a pull request to GitHub repo A, and suppose that the pull won't go through without resolving some conflicts and merging.

Therefore, in order to accept the changes proposed by B, the owner of A makes the pull request from an offline repo, performs the merge, and pushes the merge to A. Now A is at least one commit ahead of B.

How does B now update itself to be in sync with A? Can this be done entirely from within the GitHub web interface?

(I imagine that one answer to the first question would be that the owner of B could pull the contents of the A repo, and then push the resulting state to the B repo, but I was wondering if there's a way to update the B repo directly from the GitHub web interface.)

Answer 1

As far as I know the only way to achieve this using GitHub's web interface is creating a reverse pull request. This however comes at the cost of an additional merge commit which is usually not desirable as it sums up and new pull requests from B to A will include all those unneccesary commits.

It probably is possible to use the „Git Data“ API to merge some branches, but it is easier and safer to do it on the command line.

---

The strategy I recommend to others is this one:

1. Never ever modify your master or whatever the mainline branch is called
2. Base your pull request branches on your master
3. Whenever there are changes to the upstream master integrate them by fast forwarding your master to the upstream one.

That way your pull requests will stay nice and clean and you won't have issues with rejected commits popping up in subsequent pull requests.