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
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
And honestly, who's going to care about your copy of `master`? :) If anyone works off your clone it's going to be for one of your branches, not `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.
And I think the other key is using "pr" as the remote's name so that you don't want to throttle GitHub for having you type the name constantly. You could do `git push --set-upstream pr` on the first push (or as soon as you create the branch), but you would need to do 9 pushes to break even with that many keystrokes.