On Mar 06, 2016, at 12:27 PM, Nick Coghlan wrote: >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
This is essentially what I do too, but with some differences in names. Chris mentioned naming the 'upstream' remote to point to the upstream repo, and 'origin' to name his clone. I do something different, but as a general recommendation to people who are coming to this workflow previously unscathed <wink> I like Chris's suggestion. I generally only name my issue branches after the issue number, e.g. "issue1234" since I can always go to the tracker to find details, and these shouldn't be long-lived branches anyway. I'd likely name a big feature branch differently. I think the essential bit of Nick's "easy way" is that you pretty much ignore your fork's master. It's just too much work to try to keep it sync'd against upstream master. Just do a pull of upstream master when you're starting something new, and push your branches to your own fork (and many people won't be able to push to upstream's repo anyway). Then use the web ui to create a pull request from that. Cheers, -Barry
pgpEWQDXMFajX.pgp
Description: OpenPGP digital signature
_______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
