Are Git forks actually Git clones?
I keep hearing people say they're forking code in Git. Git "fork" sounds suspiciously like Git "clone" plus some (meaningless) psychological willingness to forgo future merges. There is no fork command in Git, right?
GitHub makes forks a little more real by stapling correspondence onto it. That is, you press the fork button and later, when you press the pull request button, the system is smart enough to email the owner. Hence, it's a little bit of a dance around repository ownership and permissions.
Yes/No? Any angst over GitHub extending Git in this direction? Or any rumors of Git absorbing the functionality?
Answer
Fork, in the GitHub context, doesn't extend Git.
It only allows clone on the server side.
When you clone a GitHub repository on your local workstation, you cannot contribute back to the upstream repository unless you are explicitly declared as "contributor". That's because your clone is a separate instance of that project. If you want to contribute to the project, you can use forking to do it, in the following way:
- clone that GitHub repository on your GitHub account (that is the "fork" part, a clone on the server side)
- contribute commits to that GitHub repository (it is in your own GitHub account, so you have every right to push to it)
- signal any interesting contribution back to the original GitHub repository (that is the "pull request" part by way of the changes you made on your own GitHub repository)
Check also "Collaborative GitHub Workflow".
If you want to keep a link with the original repository (also called upstream), you need to add a remote referring that original repository.
See "What is the difference between origin and upstream on GitHub?"
And with Git 2.20 (Q4 2018) and more, fetching from fork is more efficient, with delta islands.