> (...) when all I did was follow the instructions at help.github.com/forking, TO THE LETTER. Well there's your problem, to quote certain TV personality. Git

> (...) when all I did was follow the instructions at help.github.com/forking, TO THE LETTER. Well there's your problem, to quote certain TV personality. Git supports several different workflows. Each one is valid. Some of them are incompatible with one another in some cases. Now everybody gives you instructions that make sense in his workflow. The instructions are correct, you apply them correctly and get a correct result. Only that the result does not make sense in the (different, but valid as well) workflow that you use daily. That will happen sometimes if you don't make upfront a plan of what comes, or derives, from what, if you don't visualize what line of development merges into, or rebases onto, which. But hey, presto! You can always git-reset your branch (read man first!, that's powertool and must be applied with care), or git-cherry-pick (fun and easy) some changesets and you are back on track. Best thing is, if you somehow get into a tight corner, you can just remove this branch or repo and start afresh, if you haven't pushed to the server yet. Push decoupled from commit is your ultimate parachute -- and comes with a backup parachute of local branching. tl;dr: don't follow $RANDOM_INSTRUCTIONS; make a plan upfront and you'll know where you are at every step. And should that fail, deploy either parachute.