Reputation: 10887
I am trying to understand / visualize the elements that come with forking a repo. My starting reference is this help page.
1st Question:
When I forked a repo e.g. Spoon-Knife on GitHub (i.e. clicked the Fork button on their site), does it mean the Spoon-Knife is copied to my GitHub account? Did a real copy actually happen or is it just a concept?
2nd Question:
The next step in the help page is to do a clone:
$ git clone [email protected]:username/Spoon-Knife.git
This command made a copy of the source in my local machine. Did it clone from the forked / copied repo in my GitHub account (please see my first question)? Or, from the original Spoon-Knife repo?
3rd Question:
Step about configuring remotes:
When a repo is cloned, it has a default remote called
origin
that points to your fork on GitHub, not the original repo it was forked from. To keep track of the original repo, you need to add another remote namedupstream
.
So, is origin
some kind of "proxy" between our local copy and the repo copy on my GitHub account? And, how about upstream
?
Thanks beforehand for your help.
Upvotes: 4
Views: 2758
Reputation: 5357
3 repos
original - {GitHub}/octocat/Spoon-Knife
forked - {GitHub}/ mine/Spoon-Knife
local - {local} /Spoon-Knife
When you "fork", you do have an actual copy in the sense that you have read/write access to it. However, it can be best thought of as a way to effectively "create a branch on the original git repository that you can write to".
The "fork" action copied the original
to your GitHub account. You can directly push from local
clone to forked
(NOT original
).
Put simply, a remote
is a name to a repository at an external address.
"origin" - points to forked
("origin" is the default remote
name)
"upstream" - points to original
so that you can fetch changes to your repos
You can see your remotes with git remote -v
and add them easily to track any branch on any externally available git repo.
Partially derived from Mark's answer.
Upvotes: 1
Reputation: 262534
When I forked a repo e.g. Spoon-Knife on GitHub, does it mean the Spoon-Knife is copied to my GitHub account?
Yes.
Did a real copy actually happen or is it just a concept?
That is an implementation detail on Github's end. Should not matter to you. (I am pretty certain they share the storage).
Did it clone from the forked / copied repo in my GitHub account? Or, from the original Spoon-Knife repo
Since you pointed it at your user account's repo, it will have copied it from there. The contents of the two forks are identical at this point, though.
So, is origin some kind of "proxy" between our local copy and the repo copy on my GitHub account? And, how about upstream?
Not really. "origin" is just an identifier for the repo on GitHub to make it easier for you to communicate with it. "upstream" would work the same. You do not need to set up these remotes, but having them for all the repos that you frequently work with (push or pull changes) makes things easier for you. The names "origin" and "upstream" are also just conventions (with you should follow), there is no "magic" to them.
Upvotes: 1
Reputation: 44503
With git, each repository get the full history. In fact (except for some optimisation with sharing data between local repository), each repository is a clone of another repository. Or in git hub speak a fork (they are the same thing).
So you have three repository: the original developer repository, a clone on git hub (they call it a fork), and a local clone of this clone. The name origin
is just a shorthand name to refer to your repository on git hub (your first clone). Without this shorthand, you would have to give the full URI to the repository at each step.
A repository can have many such shorthand name to other repository. It is recommended they all are clone of the same original repository so that the history is a simple directed acyclic graph with a single root.
You could have worked without the intermediate clone on git hub, but since you don't have write access to the original developer repository, and it may be impractical for you to make your private repository accessible, this repository on git hub can be used as a communication gateway for patch between you and the original author.
Upvotes: 1
Reputation: 3921
You need to distinguish between the concepts of fork and clone.
clone is a Git concept that existed before GitHub: when you clone a repository, you copy all the history and data in it into your own newly-created repository. In addition, a remote is automatically created in the new repository, called origin, which points back to the repository that you cloned from.
fork is a GitHub concept that the core Git is not aware of. When you fork a GitHub project, you are creating your own GitHub project that is identical to the original, with all the GitHub features like the fork graph automatically updated. Behind the scenes, the fork also includes cloning the Git repository in the original project and creating a new Git repository in your newly-created project.
When you want to work on a GitHub project from your own private machine, you need to clone that repository first, regardless of whether it is your repository or someone else's. If you clone from your GitHub project, you'll get it as origin, but if you want the original project as a remote as well, you'll need to add that manually (and call it upstream, for example).
Upvotes: 4
Reputation: 9886
All you are doing when you "fork" is to effectively create a branch on their git repository that you can check into.
Your local copy that you clone to is just cloned from and linked to the branch you created on git-hub. Remember a branch is just a pointer to a commit object, so when you "forked" you just added a branch name on their repo that points to the current head of their master.
Remotes in git are just names to repositories at an external address. Your default "origin" is set up by git and is just a named remote. "upstream" is just another name and points to the original master that you originally branched from so that you can pull changes between master and your own branch. You can see your remotes with git remote -v
and add them easily to track any branch on any externally available git repo.
Upvotes: 4
Reputation: 12710
1st question:
You copied it. In fact it's a kind of clone. You now have a copy of the project (in fact of one of its branches) in your github account.
2nd question:
The git clone command clone the repo you give it.
So $ git clone [email protected]:username/Spoon-Knife.git
clone Spoon-Knife from the username
repo. If it is your account, so it's a copy of your copy of Spoon-Knife repo :)
3rd question:
origin
is not a proxy, it's just a name to another repo.
For example the following command add a repo named local_srv
:
git remote add local_srv /path/to/local/srv
upstream
is just another remote. You can configure it to pull from it (i.e. get updates).
In your case origin
is your github repo (I call the remote github
) and you can add upstream
remote to the original Spoon-Knife repository.
So you work in your project in local, push to your github account (e.g. git push origin master
) and get new updates of the Spoon-Knife project using git pull upstream master
.
Note : Here I only used master, but you can replace it by the branch you like.
Upvotes: 2