Versions Compared

Old Version 64

changes.mady.by.user Hardy Pottinger

Saved on

compared with

New Version 65

changes.mady.by.user Hardy Pottinger

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Creating the PR: Please, make sure to create a Pull Request from a branch and NOT from your "master". (You'll understand exactly why after reading #2)
  2. Updating the PR: To update the Pull Request just simply add a new commit to the branch it was created from. Conversely, be warned that any additional changes/commits you make to that PR branch (before the "Pull Request" is accepted/merged) will immediately be included in that existing "Pull Request". This means that, if you want to continue your local development, you must create that "Pull Request" from a semi-static branch (so that any additional commits you make on your local "master" in the meantime don't get auto-included as part of your existing Pull Request).
    • The reason why this occurs is that a "Pull Request" just points at a specific "branch" (the branch it was initialized from). It does NOT point at a specific set of commits. So, when the "Pull Request" is accepted/merged, you are pulling in the latest version of that "branch". For more information, closely read the GitHub help page on Using Pull Requests, specifically noting the following statement:

      Pull requests can be sent from any branch or commit but it’s recommended that a topic branch be used so that follow-up commits can be pushed to update the pull request if necessary.

  3. Communicating about your PR: Once your Pull Request is created, you can use the GitHub Pull Request tools to communicate with the Committer who is assigned to the Pull Request. If further changes are requested, you can make those changes on the branch where you initiated the Pull Request (and those changes will automatically become part of the Pull Request, as described above)
  4. Squashing or cleaning up your PR: If you ever want to "clean up" your Pull Request, we recommend using 'rebase' to "squash" several related commits into one. Here's a good example: http://stackoverflow.com/a/15055649 (see the section on "Cleaning Commit History")

  5. Rebasing your PR: As commits are merged into the master branch over time (via merges of other pull requests) your own pull request will probably need updating. This is a fairly straightforward operation, however, it can also easily go wrong. Here's a quick overview of the commands you'll need to run:

    Code Block
    cd YOUR_WORKING_COPY_PATH
git fetch --all
git checkout master #may have to git stash first, but, don't forget, you need to be ON THE MASTER BRANCH before you proceed
git pull upstream master
git push origin master
git pull origin master #not necessary but a nice sanity check
git checkout BRANCHNAME
git rebase -i master

    The third step above is crucial: you must be on the master branch before you proceed with the remaining steps. Sucessfully checking out the master branch may require you to first run {code}git stash{code} to set aside your work in progress. Doing so may send you off running a series of commands, and you may lose track of where you are going. If you accidentally run {code}run git pull upstream master{code} in your own branch, your pull request will show many (possibly hundreds) of unrelated commits. It's difficult, though not impossible, to reverse this situation. The Git Pretty poster can help you resolve such situations.

...