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。