Maybe there’s a bit of confusion about the terms clone and fork here, which we might want to clear out. In Git terminology, a clone usually refers to a local copy of a repository, whereas a fork usually refers to a derived copy of an original repository, in this case the fork would be hosted on GitHub.
So, let’s say there’s repository X (on GitHub), and you want to contribute to it. In the GitHub Workflow the customary way to do this if to fork X to your account, then you clone locally your fork of X, not the original X repository — i.e. when you execute
git clone you provide the URL of your fork (e.g.
wajika/x). The reason for this is that (unless you are invited as a collaborator to the X repository) you won’t have write access to the repository, so you need to create your own copy (your fork) under your account, which of course gives you write access privileges to it.
In your local copy of the repository you’ll have two remotes:
origin — pointing to your fork of X, under your account.
upstream — pointing to the original X repository on GitHub.
You’ll be pulling from
upstream in order to integrate updates and changes from the original repository into your local clone, and then push them to
origin to keep your fork updated on GitHub.
Bear in mind that Git is a distributed version control system, so the fact that we consider the repository X on GitHub the “original” repository is more of a convention than a technical constraint.
For the same reason, you don’t need to delete your current local clone to connect it to your new fork of X, because a repository is just a repository, and you can simply add and delete remotes as you please. A remote is a “pointer” to a source of data for that repository. Since you originally cloned X, making it now point also to your new fork won’t compromise its data, you’ll only have to hook it to point to the new remote and keep doing your usual Git operations.
Even if you destroy a remote, the repository integrity is still there, and when you add a new remote Git has its own ways to check that the local repository and that present at the remote are indeed the same repositories.
As for pull requests, indeed the GitHub Workflow requires you to apply your changes to a custom branch that is pushed on your fork, and then you open a PR on the target repository (i.e. the original X, or upstream). That is, unless you are a collaborator of the X repository, in which case you can push your changes directly on the original repository, and create a request therein, or even skip the pull request part and directly merge your changes into the
main branch (if this is how you agreed to work with the owner of the repository).
You might want to learn more about the GitHub Workflow, which is the way collaboration works here on GitHub (and similarly in other Git hosting services too):
I hope this helped.