Talk:Git for Wesnoth Crash Course
I would recommend a different thinking here. It is explained wayyyy to complex.
Normally you have some git repo from a project.
Normally you clone it first to see if you can work with it.
If you clone it directly from the projects github account, this will be your "origin".
If you want to change something on the origin, you can't push back, because you have no rights and the workflow is different.
You should create a fork and set it as your upstream (tracking).
This way you will always have origin as the pull target and your fork as your push target.
If you push something to your fork and you are done with your task, you can offer a pull-request to the projects repo.
They can look on your code and see if they like it and pull it into their repo (and spreading it to all the other devs)
how to do it?
TBD
Refering to Upstream (as related to) Tracking in [[1]] On the other hand, @{upstream}'s meaning for GIT is unique : it is 'the branch' (if any) on 'said remote', which is tracking the 'current branch' on your 'local repository'.
It's the branch you fetch/pull from whenever you issue a plain git fetch/git pull, without arguments.
Git Branching and Workflow with forked public repo:
http://git-scm.com/book/ch5-2.html