Git 叉子实际上是 Git 克隆吗？
我一直听到有人说他们在 Git 中提供代码。 Git“fork” 听起来像 Git“克隆”，还有一些（毫无意义的）放弃未来合并的心理意愿。 Git 中没有 fork 命令，对吧？
GitHub 通过将对应关系固定到它上来使叉子变得更加真实。也就是说，您按下前叉按钮后，当您按下拉取请求按钮时，系统足够智能，可以通过电子邮件发送给所有者。因此，它是围绕存储库所有权和权限的一点点舞蹈。
是 / 否？对 GitHub 的任何焦虑都会向这个方向扩展 Git？或者 Git 吸收功能的任何谣言？
答案
在 GitHub 上下文中， Fork不会扩展 Git。
它只允许在服务器端克隆。
在本地工作站上克隆 GitHub 存储库时，除非明确声明为 “贡献者”，否则无法返回上游存储库。那是因为你的克隆是该项目的一个单独的实例。如果您想为项目做出贡献，可以通过以下方式使用分叉来执行此操作：
- 克隆你的 GitHub 帐户上的 GitHub 存储库（即“fork” 部分 ，服务器端的克隆）
- 贡献对 GitHub 存储库的提交（它在你自己的 GitHub 帐户中，所以你有权利推送它）
- 将任何有趣的贡献发送回原始的 GitHub 存储库（即通过您在自己的 GitHub 存储库上所做的更改的“拉取请求” 部分 ）
另请参阅 “ Collaborative GitHub Workflow ”。
如果要保留与原始存储库（也称为上游）的链接，则需要添加引用该原始存储库的远程数据库。
请参阅 “ GitHub 上的源和上游有什么区别？ ”
使用 Git 2.20（2018 年第四季度）以及更多， 使用delta 岛更有效率。
我一直听到有人说他们用 git 代码。 Git“fork” 听起来像 git“clone”，加上一些（无意义的）放弃未来合并的心理意愿。 git 中没有 fork 命令，对吧？
“分叉” 是一个概念，而不是任何版本控制系统特别支持的命令。
最简单的分叉是分支的同义词。每次创建分支时，无论您的 VCS 如何，您都 “分叉” 了。这些叉子通常很容易合并在一起。
你正在谈论的那种分支，一个单独的一方获取代码的完整副本并走开，必然发生在 VCS 之类的集中式系统中，如 Subversion。像 Git 这样的分布式 VCS 可以更好地支持分支整个代码库并有效地启动新项目。
Git（不是 GitHub）本身支持以几种方式 “分叉” 整个回购（即克隆它）：
- 克隆时，会为您创建一个远程调用
origin - 默认情况下，克隆中的所有分支都将跟踪其
origin等价物 - 从您分叉的原始项目中获取和合并更改非常简单
Git 将更改贡献给 fork 的源代码就像要求原始项目中的某些人从您那里获取，或者请求写访问权来自行推送更改一样。这是 GitHub 更容易和标准化的部分。
对 Github 的任何焦虑都会向这个方向扩展 git？或者任何关于 git 吸收功能的谣言？
没有焦虑，因为你的假设是错误的。 GitHub 通过一个漂亮的 GUI 和一个标准化的发布拉取请求的方式 “扩展” 了 Git 的分叉功能，但它没有向 Git 添加功能。完全复制分叉的概念在基础层面上直接进入分布式版本控制。您可以随时放弃 GitHub 并继续推送 / 拉动您 “分叉” 的项目。
是的，fork 是一个克隆。它的出现是因为， 未经他们的许可 ， 你不能将他人的副本推送给他人 。他们为你制作了一份副本 （ fork ），你也有写权限。
将来，如果实际的所有者或其他用户拥有类似您的更改的分支，他们可以将其拉回到自己的存储库中。或者，您可以向他们发送 “拉动请求”。