(In addition to the official “GitHub Help ‘Using pull requests’ page“,
see also “Forking vs. Branching in GitHub“, “What is the difference between origin and upstream in GitHub“)
Couple tips on pull-requests:
Assuming that you have first forked a repo, here is what you should do in that fork that you own:
- create a branch: isolate your modifications in a branch. Don’t create a pull request from
master, where you could be tempted to accumulate and mix several modifications at once. - rebase that branch: even if you already did a pull request from that branch, rebasing it on top of
origin/master(making sure your patch is still working) will update the pull request automagically (no need to click on anything) - update that branch: if your pull request is rejected, you simply can add new commits, and/or redo your history completely: it will activate your existing pull request again.
- “focus” that branch: i.e., make its topic “tight”, don’t modify thousands of class and the all app, only add or fix a well-defined feature, keeping the changes small.
- delete that branch: once accepted, you can safely delete that branch on your fork (and
git remote prune origin). The GitHub GUI will propose for you to delete your branch in your pull-request page.
Note: to write the Pull-Request itself, see “How to write the perfect pull request” (January 2015, GitHub)
March 2016: New PR merge button option: see “Github squash commits from web interface on pull request after review comments?“.
The maintainer of the repo can choose to merge --squash those PR commits.
After a Pull Request
Regarding the last point, since April, 10th 2013, “Redesigned merge button“, the branch is deleted for you:
Deleting branches after you merge has also been simplified.
Instead of confirming the delete with an extra step, we immediately remove the branch when you delete it and provide a convenient link to restore the branch in the event you need it again.
That confirms the best practice of deleting the branch after merging a pull request.
pull-request vs. request-pull
-
pull request isn’t an official “git” term.
Git uses therequest-pull(!) command to build a request for merging:
It “summarizes the changes between two commits to the standard output, and includes the given URL in the generated summary.”
Github launches its own version on day one (February 2008), but redesigned that feature in May 2010, stating that:Pull Request = Compare View + Issues + Commit comments
e-notes for “reposotory” (sic)
<humour>
That (pull request) isn’t even defined properly by GitHub!
Fortunately, a true business news organization would know, and there is an e-note in order to replace pull-replace by ‘e-note’:
So if your reposotory needs a e-note… ask Fox Business. They are in the know.
</humour>