GitHub中的Project vs Repository


185

在GitHub中,项目(可以在存储库内部创建)和存储库之间在概念上有什么区别?

我看过几个类似的问题(在这里这里这里在SO中),但是没有一个解释什么是GitHub项目,什么是GitHub存储库以及何时使用每个问题。

如果有人可以解释每个术语,并提供何时使用/创建每个术语的示例,我将不胜感激。例如,如果我有几个相互独立的原型应用程序,那么我应该创建什么以便以有组织的方式管理所有应用程序的源代码?


1
github存储库只是文件和文件夹可以存在的“目录”。其他人可以创建自己的“目录”副本并根据需要对其进行修改,然后请求将其更改放入主存储库。至于项目,我不确定,因为我从未使用过它们。
byxor

1
您说您曾经看到过类似的问题,但您是否真正阅读了第一个链接?“这是一个令人震惊的事情,而不是git的事情。每个项目可以有多个存储库。” 在同一线程上的另一个答案是“ Git没有项目,只有存储库”。如果您确实确实是github项目的意思,我建议您查看有关它的github文档help.github.com/articles/…–
PeeHaa

6
@PeeHaa是的,我做到了。第一句话说:“这是一个奇妙的事情,而不是git的事情。每个项目可以有多个存储库。” 对我来说,这里谈论的是Gitorius,而不是GitHub。另外,它说在Gitorious中,每个项目可以有多个存储库,但是在GitHub中则相反。因此,如果您能解释一下如何回答我的问题,我将不胜感激。
carlossierra

2
我认为,这涉及到语义上的语义,其中新功能Projects(可视化面板)与Project术语的超载用法相冲突。否决票可能不是程序设计问题。
osowskit

2
这应该具有您需要的一切github.com/blog/…–
osowskit

Answers:


105

GitHub最近推出了一项名为Projects的新功能。这提供了许多项目管理工具所特有的可视化板:

项目

GitHub上记录的存储库

存储库是GitHub的最基本元素。最容易将它们想象为项目的文件夹。资源库包含所有项目文件(包括文档),并存储每个文件的修订历史记录。存储库可以有多个合作者,可以是公共的也可以是私有的。

一个项目GitHub上记录的:

GitHub上的项目板可帮助您组织工作并确定其优先级。您可以为特定功能工作,综合路线图甚至发布清单创建项目板。使用项目板,您可以灵活地创建适合您需求的定制工作流。

造成混淆的部分原因是,新功能Projects与以上文档中术语project的重载使用冲突。


1
因此,我正在使用Github来存储我的个人研究项目A,B,C等的代码。如果我正确地理解它,那么每个研究项目都会得到它自己的存储库?那么A得到一个存储库,B得到一个存储库,C得到一个存储库,等等?
底座

派生存储库时,派生可以访问项目板的快照吗?
地理定位

6
如何选择这个作为可接受的答案?只需复制所描述的内容即可。OP可以读取它,但是人们希望通过简单的示例来了解。
batmaci

147

事实1:项目和存储库在GitHub上始终是同义词。

事实2:情况已不再如此。

关于存储库和项目有很多困惑。过去,用户和GitHub自己的文档几乎可以互换使用这两个术语。此处的一些答案和评论反映了这一点,这些答案和评论解释了这些术语之间的细微差别,以及何时优先使用一个术语。差异总是细微的,例如,问题跟踪器是项目的一部分,而不是资源库的一部分,而后者可能被视为严格的git等。

不再。

当前,回购和项目指是具有不同API不同种类的实体

从那时起,将回购称为项目即不再正确,反之亦然。请注意,官方文档中经常将其混淆,不幸的是,已经选择了一个已经被广泛使用的术语作为新实体的名称,但事实确实如此,我们必须忍受这一事实。

结果是,回购和项目通常会混淆,每次您阅读有关GitHub项目的信息时,您都不得不怀疑它是否真的与项目或回购有关。如果他们选择了其他名称或缩写,例如“ proj”,那么我们可以知道所讨论的是新类型的实体,具有具体属性的精确对象,或者从总体上讲像回购协议一样的东西。

通常明确的术语是“项目委员会”

我们可以从API中学到什么

Projects API文档中的第一个端点:

描述为:列出存储库项目。这意味着存储库可以具有许多项目。因此,这两个含义不相同。如果项目被禁用,它包括响应

{
  "message": "Projects are disabled for this repo",
  "documentation_url": "https://developer.github.com/v3"
}

这意味着某些回购可能会禁用项目。同样,当一个回购可以禁用项目时,这些不可能是同一件事。

还有一些其他有趣的端点:

  • 创建一个存储库项目 -POST /repos/:owner/:repo/projects
  • 创建一个组织项目 -POST /orgs/:org/projects

没有

  • 创建用户的项目 -POST /users/:user/projects

这导致我们得出另一个差异:

1.存储库可以属于用户或组织
2.项目可以属于存储库或组织

或者,更重要的是:

1.项目可以属于存储库,但不能属于其他方式
2.项目可以属于组织,但不能
属于用户3.存储库可以属于组织和用户

也可以看看:

我知道这很混乱。我试图尽我所能解释它。


在Atlassian的Bitbucket中,您可以创建包含一系列相关回购协议的项目。Github是否具有此组织功能?我原以为Github Projects就是那样,但事实并非如此。我似乎无法弄清楚如何使这个组织在Github中成为可能。我非常习惯Bitbucket,所以它可能只是学习曲线。
Ungeheuer

以某种方式,如果一个项目可以有多个存储库,那对我来说更有意义。我的印象是GitHub注意到它已经过时了,而不是进行彻底的重新设计,而只是选择了一种解决方法并将其出售为一件好事。顺便说一句,现在GitHub的所有者是谁?也许答案给出了为什么会这样的线索。只是大声思考。
Almir Campos

19

GitHub存储库用于存储您关心的所有文件,文件夹和其他资源。

Git项目:它也是Git存储库中的资源之一,它的主要用途是使用可视面板管理项目。如果您在Git Repository中创建一个项目,它将创建一个看板(例如看板)来管理该项目。

这样,您可以在存储库中拥有多个项目。


4

通常,在GitHub上,1个存储库= 1个project。例如:https : //github.com/spring-projects/spring-boot。但这不是硬性规定。

1个存储库=许多项目。例如:https : //github.com/donhuvy/java_examples

1个项目=许多存储库。例如:https : //github.com/zendframework/zendframework(1个名为Zend Framework 3的项目有61 + 1 = 62个存储库,不相信吗?让我们计算一下Zend Frameworks的模块+主存储库)

我完全同意@Brandon Ibbotson评论

GitHub存储库只是其中可以存在文件夹和文件的“目录”。


感谢您的答复。但是我不认为您对项目的定义就是GitHub所说的项目,因为多项目存储库的示例在这些存储库的“项目”选项卡中未显示任何内容。您能详细说明一下吗?
carlossierra

2
实际上,使用Zend Framework的示例是完全错误的!根据GitHub的命名法,有一个名为“ zendframework”的组织,该组织拥有许多存储库,包括一个也称为“ zendframework”的存储库,以及一个用于框架每个模块的存储库。
igorcadelima

3
2017年11月9日:的实例1个库=许多项目返回404
布拉姆Vanroy

1
链接断开
Pmpr

1
就GitHub而言,此答案与上述其他更流行的答案相冲突。
Manohar Reddy Poreddy

1

关于git词汇,项目是实际内容(文件)所在的文件夹。而Repository(repo)是git用来保存项目文件夹中所做的每个更改的记录的文件夹。但从一般意义上讲,这两个可以视为相同。 项目=存储库


1

在我的理解上,概念上的区别是,一个项目可以包含许多回购且彼此独立,而一个回购可能包含许多项目。回购只是代码存储的地方,而项目则是特定功能的任务的集合。

那有意义吗?大型仓库可以有多个项目同时由不同的人处理(将很多不同的功能添加到整体中),大型项目可能有许多单独的小型仓库,但是属于同一项目的一部分可以与每个仓库交互其他-微服务?它是您要做什么的个人看法。我认为回购(存储)与项目(任务)是主要区别-如果我错了,请让我知道/解释!谢谢。


0

这是我对该主题的个人理解。

对于项目,我们可以通过不同的存储库进行版本控制。对于存储库,它可以管理整个项目或部分项目。

关于您的项目(几个相互独立的原型应用程序)。您可以通过一个或多个存储库来管理项目,区别在于:

  1. 由一个存储库管理。如果更改了一个应用程序,则整个项目(所有应用程序)将被提交到新版本。

  2. 由多个存储库管理。如果更改了一个应用程序,则只会影响管理该应用程序的存储库。其他存储库的版本未更改。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.