Are git forks actually git clones?

2018-06-15 22:36:34

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 repo ownership and permissions.

Yes/No? Any angst over Github extending git in this direction? Or any rumors of git absorbing the functionality?

Fork , in the GitHub context, doesn't extend Git.
It only allows clone on the server side.

When you clone a GitHub repo on your local workstation, you cannot contribute back to the upstream repo 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 repo on your GitHub account (that is the "fork" part, a clone on the server side)

contribute commits to that GitHub repo (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 repo (that is the "pull request" part by way of the changes you made on your own GitHub repo)

Check also "Collaborative GitHub Workflow".

If you want to keep a link with the original repo (also called upstream), you need to add a remote referring that original repo.
See "What is the difference between origin and upstream in github"

叉和上游

I think you have a funny idea of what "forking" means. It is a concept, not a command specifically supported by any version control system.

The simplest kind of forking is synonymous with branching. Every time you create a branch, regardless of your VCS, you've "forked". These forks are usually pretty easy to merge back together.

The kind of fork you're talking about, where a separate party takes a complete copy of the code and walks away, necessarily happens outside the VCS in a centralized system like Subversion. A distributed VCS like Git has much better support for forking the entire codebase and effectively starting a new project.

Git (not GitHub) natively supports "forking" an entire repo (ie, cloning it) in a couple of ways:

when you clone, a remote called origin is created for you

by default all the branches in the clone will track their origin equivalents

fetching and merging changes from the original project you forked from is trivially easy

Git makes contributing changes back to the source of the fork as simple as asking someone from the original project to pull from you, or requesting write access to push changes back yourself. This is the part that GitHub makes easier, and standardizes.

Any angst over Github extending git in this direction? Or any rumors of git absorbing the functionality?

There is no angst because your assumption is wrong. GitHub "extends" the forking functionality of Git with a nice GUI and a standardized way of issuing pull requests, but it doesn't add the functionality to Git. The concept of full-repo-forking is baked right into distributed version control at a fundamental level. You could abandon GitHub at any point and still continue to push/pull projects you've "forked".

Yes Fork is a clone. It emerged because, you cannot push to others' copies without their permission . What they do is make a copy of it for you (fork), where you will have write permission as well.

In the future if the actual owner or others users with a fork like your changes they can pull it back to their own repo. Alternatively you can send them a "pull-request".

链接地址: http://www.djcxy.com/p/45182.html

上一篇: 只在GitHub上发送一个pull请求，仅用于最新的提交

下一篇: git叉子是否是git克隆？