Read the code diff to see if it’s a good change you want to make to your project. If you can’t tell from just the diff, you can add their fork as a Git remote and check out their branch so you can run/test/preview your project with their proposed changes.

If you like their work, just click “Merge pull request”. Your repo on GitHub will be updated. Then you can pull from your GitHub repo to your local repo to make sure you’re working on the version of the code including their changes. If you want, also post a comment in the pull request thanking the contributor.

If you don’t like their work, post a comment saying why you don’t want to pull. If they just have small style problems, or the feature has a bug in it or is missing docs, describe what’s wrong or what still needs to be added or decided. You and other contributors might end up discussing what else needs to be added, using comments. The creator of the pull request can update the code in their branch at any time to accommodate feedback. At the point that their code is good enough, just click “Merge pull request”.

If the pull request is something that can’t be salvaged – it’s out of scope for the project or you think it is an anti-feature – explain that in a comment, and close the pull request at the same time. Pull requests can always be closed or reopened later, and can be commented on whatever state they’re in, so the closed state is mainly for communicating whether you expect that you will eventually merge that pull request or a later update of it.

Thanks! I guess a problem I have is they've been sitting out there a while and my code base has changed a lot since they were posted. Any tricks there or would I just have to go through change by change?

If your code has changed enough that GitHub can’t automatically do the merge, you have to either do the merge yourself or ask the submitter to do it.

I expect that GitHub lets you do the merge yourself by adding the submitter’s fork as a remote to your clone and then doing a local merge with all your command-line tools, and finally pushing your merged version to GitHub. But I’ve never been in the situation to try it. I guess this would be what you call going through change by change. I’m afraid I don’t have any tips for doing merges in general.

If you’d rather ask the submitter to do the merge, post a comment in the issue saying “Sorry it took me so long to get to this. This diff no longer merges cleanly. Please merge the latest version of my code onto your branch, and I’ll merge your pull request right after that.” You can either ask them to update the branch in the existing pull request, or close that issue and ask them to create a new pull request for their new version.

What I like to do is to fetch the proposed changes on my local repo, but without committing them (`--no-commit`):

- fetching locally: easy to test on your dev box

- without committing: easy to see what files are changed in your directory, and to diff files on your dev box