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@gmail.com | Brisbane, Australia