CODEWITHSUNDEEP
gitgithubmergeopen-sourcepull-request
Luke Schlangen
Luke Schlangen

Reputation: 3882

The right way to resolve pull request merge conflicts on Github from separate fork

I am currently maintaining my first open source projects and I keep running into the same scenario.

  1. I get two Pull Requests within a few minutes
  2. Both Pull Requests look great and don't conflict with the master branch. I want to merge them both into master.
  3. I merge the first Pull Request and works great.
  4. I go back to the second Pull Request and now there are conflicts

What I want to do is resolve the conflicts for the contributor. The conflicts are often small and not worth asking the contributor to go through the process of rebasing. The problem is, I can't always do it in the Github online editor, and if I follow the steps laid out by Github to make the changes in terminal, I end up making my own branch, my own Pull Request, and the contributor's Pull Request ends up getting unceremoniously closed!

I know that technically, the code is the same in the end, but it seems pretty crumby to close the Pull Request that just happens to be the one I choose to merge in second. Is there a better way to do this? Am I misunderstanding something?

I think the question I'm trying to ask is, "Can I make changes and push to a branch on a fork that came from my repository, even if it is not my fork?" That way, the Pull Request would automatically update with the resolution I created and I can pull in the changes.

Upvotes: 4

Views: 1501

Answers (1)

msanford
msanford

Reputation: 12247

I, too, have encountered this on active repos (particularly during Hacktoberfest).

Direct Answer

To answer your question, no, you can only push to a repository that someone has explicitly given you push access to.

The fact that is a fork of your repository is only tracked for informational purposes, since I can just as easily create a fork by cloning your project and pushing to my own remote.

Meta

It's nice of you not to want to "bother" the contributor to fix those conflicts, but they really should. That's just how the PR model works.

Now, you could:

  • Add their branch as a remote to your own working copy
  • Pull
  • Fix conflicts
  • Push your own branch
  • Merge that branch

But that would seem to 'rob' the contributor of part of the experience, as well as a merged PR.

The bigger problem for you as a maintainer is that this does not scale. It's fine if you have two small PRs with white-space-only conflicts, but it very quickly becomes unmanageable. So don't get into the habit of doing that. The only exception would be an urgent/breaking/security fix that you cannot wait to merge.

Upvotes: 4

Related Questions