You should have write access to your fork, which is why you need to push your changes from your local clone (of your fork, not of the original repository) into your fork on GitHub, and only then you can create a pull request on GitHub’s WebUI. Pull requests are not part of Git, they are part of GitHub, which is why you need to create them on GitHub, not via Git commands. If you’re a collaborator to the repository than you have already write access, and don’t need to fork it since you can create PRs directly on the upstream repository. If not, you need to fork, push your changes to your fork (on a new branch) and then create the PR on the target repository (usually the usptream, i.e. original).
From your fork you can create a pull request to any repository which shares the same history of the branch you’re making the PR on. Branches are what allow Git users to keep divergent code along with the original code. What is considered the main code by someone might depend on what one is working with. E.g. let’s say that repo A is the “official” version of some program, but then someone created a variation of the same program, which is hosted on repo B. The two projects have a common history, which is what allows them to pick and chose updates from each other.
Since both A and B are connected via some common branch which they share, in your repository (let’s call it X) you can fork A, but then also add a remote pointing to B, so you’ll be able to pull changes from both, and also submit changes to both. The idea of a “central” and “official” repository is nothing more than a convention in Git, because it’s a decentralized system. Of course, we all know that certain apps have an official repository, but if they are open source nothing prevents you from creating different versions of that app (which are called forks).