[core-workflow] Spelling out a suggested local workflow for sending PRs?

[Nick Coghlan]

Something that came up at work recently was instructing people on how best
to configure local git clones for working with a "fork+PR" development
model, where you have your own server-side fork for the project that you
then use to submit pull requests. The trick is that there's an easy way to
do this and a hard way, and it isn't immediately obvious which is which :)

The easy way:

* clone the upstream repo read-only
* add your fork as an additional read/write remote:
  * e.g. "git remote add pr <URL of fork>"
* work in a branch
  * e.g. "git checkout master && git checkout -b issueNNNN-summary-of-issue"
* publish via your fork, and then submit back to the main repo
  * "git push pr"
  * use the web UI to submit the PR

The hard way:

* clone your fork read/write
* still work in topic branches
* waste time keeping master in your fork up to date
* forget the previous step, and submit PRs against a stale version of master

I bring it up as when I first started using GitHub, the second way seemed
intuitively obvious to me, but it actually makes things harder than they
need to be.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160306/3c1778ee/attachment.html>