git叉子是否是git克隆？
我不断听到人们说他们在git中分配代码。 Git“fork”听起来像git“clone”，加上一些（毫无意义的）放弃未来合并的心理意愿。 在git中没有fork命令，对吧？
Github通过将信件装订到它上面，使分叉变得更真实。 也就是说，您按下叉子button，然后当您按下“请求”button时，系统足够聪明，可以向所有者发送电子邮件。 因此，这对回购所有权和许可权有一点点的影响。
是/否？ Github上的任何焦虑都会在这个方向上延伸git？ 或者任何有关git吸收function的传言？
在GitHub上下文中， 叉不会扩展Git。
它只允许服务器端的克隆。
当您在本地工作站上克隆一个GitHub仓库时，除非明确声明为“贡献者”，否则无法回馈到上游仓库。 这是因为你的克隆是该项目的一个单独的实例。 如果您想为项目做出贡献，可以使用分叉来完成，方法如下：
- 克隆GitHub账户上的GitHub仓库（即“fork”部分 ，服务器端的克隆）
- 贡献到该GitHub回购（这是在你自己的GitHub帐户，所以你有权利推动它）
- 向原始的GitHub回购（即“拉取请求”部分 ）发出任何有趣的贡献，
请检查“ 协作GitHub工作stream程 ”。
如果你想保持原始回购（也称为上游）的链接，你需要添加一个远程引用原始回购。
请参阅“ github中的起源与上游之间的区别 ”
我不断听到人们说他们在git中分配代码。 Git“fork”听起来像git“clone”，加上一些（毫无意义的）放弃未来合并的心理意愿。 在git中没有fork命令，对吧？
我认为你对“分叉”的含义有一个有趣的想法。 这是一个概念，而不是任何版本控制系统特别支持的命令。
最简单的分叉就是分支的代名词。 每当你创build一个分支时，不pipe你的VCS如何，你已经“分叉”了。 这些叉子通常很容易合并在一起。
你所谈论的那种分支，其中一个独立的方拿走了代码的完整副本，然后离开，必然发生在VCS之外的一个集中式系统中，比如颠覆。 像Git这样的分布式VCS对分叉整个代码库和有效地开始一个新项目提供了更好的支持。
Git（而不是GitHub）本身支持“分叉”整个回购（即克隆它）在几个方面：
- 当你克隆时，为你创build一个远程调用的
origin - 默认情况下，克隆中的所有分支都将跟踪它们的
origin等价物 - 从原来分出的项目中获取和合并更改非常简单
Git将贡献变化回到fork的源头，就像从原始项目中请求某个人从你那里拉出来一样简单，或者请求写入访问来推动变化。 这是GitHub变得更容易和标准化的部分。
Github上的任何焦虑都会在这个方向上扩展Git吗？ 或者任何有关git吸收function的传闻？
没有焦虑，因为你的假设是错误的。 GitHub使用一个漂亮的GUI和一个发出pull请求的标准方式“扩展”了Git的分叉function，但是它并没有为Git 添加function。 全分布式的概念从根本上被分解为版本控制。 你可以随时放弃GitHub，并继续推/拉你分叉的项目。
是叉是一个克隆。 这是因为， 没有他们的许可 ， 你不能推他人的副本 。 他们所做的是为你制作一个副本 （ fork ），在那里你也有写权限。
将来如果实际的拥有者或其他用户使用一个类似于您的更改的分支，他们可以将其恢复到自己的回购。 或者，你可以发送一个“拉请求”。
在这种情况下，“叉”意味着“制作他们的代码副本，以便我可以添加自己的修改”。 没有什么别的可以说了。 每个克隆本质上都是一个分支，决定是否从分支中提取变更取决于原始数据。
克隆包括将git仓库的副本复制到本地机器，而分叉则将仓库复制到另一个仓库。 克隆仅供个人使用（尽pipe将来可能会合并），但是分叉是为了复制并打开一个新的可能的项目path
我认为叉是其他存储库的副本，但与您的帐户修改。 例如，如果直接在本地克隆其他存储库，远程对象的来源仍在使用您从中克隆的帐户。 你不能提交和贡献你的代码。 这只是一个纯粹的代码副本。 否则，如果您分配一个存储库，它会克隆您的帐户设置更新您的github帐户回购。 然后在您的帐户的上下文中克隆回购，您可以提交您的代码。
当您决定参与某个项目时，分叉就完成了。 您将制作整个项目的副本以及其历史日志。 此副本完全在您的存储库中完成，一旦您进行这些更改，就会发出拉取请求。 现在，它到源的所有者接受您的拉取请求，并将更改合并到原始代码。
Git的克隆是一个实际的命令，允许用户获得源的副本。 git clone [URL]这应该在你自己的本地仓库中创build一个[URL]的副本。
除了克隆是从服务器到你的机器的，克隆是在服务器本身上复制的，一个重要的区别是当我们克隆的时候，我们实际上得到了所有的分支，标签等等。但是当我们分叉的时候，只能得到主分支中的当前文件，除此之外没有其他的东西。 这意味着我们不会得到其他分支机构等。因此，如果你必须合并回原始回购，这是一个回购合并，肯定会需要更高的特权。
叉子不是git中的命令，它只是Github实现的一个概念。 记住Git被devise为在对等环境中工作，而不需要与任何主副本同步东西。 服务器只是另一个同行，但我们把它看作一个主副本。
这里有一个关于什么是“叉”的误解。 实际上，分叉只不过是一组每个用户分支。 当你推到一个叉子，你实际上推到原来的回购，因为这是唯一的回购。
你可以通过推送到一个分叉，注意到提交，然后去原始的仓库，并使用提交ID，你会看到，提交是“在”原始回购。
这很有道理，但是很不明显（我最近偶然发现了这个）。
当John forks回购SuperProject时，似乎真正发生的事情是源回购中的所有分支都被复制了一个名字，如“John.master”和“John.new_gui_project”等
Github“隐藏”“John”。 从我们这里，给我们一个错觉，我们在Github有自己的“复制”回购，但是我们并不需要。
所以我的fork的分支“master”实际上被命名为“Korporal.master”，但Github UI永远不会显示这个，只显示我“master”。
基于我最近在做的事情，当我思考这个问题的时候，我觉得这是非常好的devise。
基于这个原因，我认为微软很容易在他们的Visual Studio Team Services服务中实现Git forks。
