<div dir="ltr"><div><div><div><div><div>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 :)<br><br></div>The easy way:<br><br></div>* clone the upstream repo read-only<br></div>* add your fork as an additional read/write remote:<br></div><div>  * e.g. "git remote add pr <URL of fork>"<br></div>* work in a branch<br></div><div>  * e.g. "git checkout master && git checkout -b issueNNNN-summary-of-issue"<br></div>* publish via your fork, and then submit back to the main repo<br><div><div>  * "git push pr"<br></div><div>  * use the web UI to submit the PR<br></div><div><div><div><div><div><div><div><br></div><div>The hard way:<br><br></div><div>* clone your fork read/write<br></div><div>* still work in topic branches<br></div><div>* waste time keeping master in your fork up to date<br></div><div>* forget the previous step, and submit PRs against a stale version of master<br><br></div><div>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.<br></div><div><br></div><div>Cheers,<br></div><div>Nick.<br clear="all"></div><div><div><br>-- <br><div class="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div></div></div></div></div></div></div></div></div>