To merge or not to merge, that is the question
When you get pull requests, be it a bug fix, an improvement or a new feature implementation, you should be grateful and happy.
But what if something in the pull request isn't quite right?
Missing tests? Not properly rebased? Non-descriptive commit messages?
The hidden powers of Github pull requests
This is something that isn't really obvious but the following method allows you to effectively edit an incoming pull request and merging it in one go.
Step 1: Pull their branch into a new branch in your local copy
Say Alice has a pull request from Bob's
fix branch to your (blessed)
origin repository on branch
master. She'll now pull in his changes into a new local branch:
$ git checkout -b bobs_pr $ git pull email@example.com:bob/the-repository.git fix
This pulls the changes made in
fix (replace this with the remote branch in the pull request) into Alice's new local branch, called
Step 2: Edit as it were nothing special
Now you can make all the changes you want by editing, commiting, squashing commits, etc.
Step 3: Push it to the (blessed) remote
This sounds strange at first, but it's nothing to be worried about.
When things are in a state where you want to merge the PR and your additional changes, you push them to the remote. If you happen to have your own fork from a blessed repository, push it to the blessed repository instead of your own fork.
$ git push origin bobs_pr:master
This will bring in the changes from the pull request as well as your additional changes and close the pull request automatically.
The pull request is closed, because all the changes from the pull request are now in the destination repository and branch, so there's nothing to do for the pull request anymore.
Smart move, Github.