Projet vs référentiel dans GitHub

Dans GitHub, quelle est la différence conceptuelle entre un projet (qui peut être créé dans un référentiel) et un référentiel?

J'ai vu plusieurs questions similaires ( ici , ici et ici ) dans SO, mais aucune d'entre elles n'explique ce qu'est un projet GitHub, ce qu'est un référentiel GitHub et quand utiliser chacun d'eux.

J'apprécierais que quelqu'un puisse expliquer chaque terme et donner un exemple de quand utiliser / créer chacun d'eux. Par exemple, si j'ai plusieurs applications prototypes, toutes indépendantes les unes des autres, que dois-je créer pour gérer de manière organisée le code source de chacune d'elles?

GitHub a récemment introduit une nouvelle fonctionnalité appelée Projets . Cela fournit un tableau visuel typique de nombreux outils de gestion de projet:

Un référentiel tel que documenté sur GitHub:

Un référentiel est l'élément le plus basique de GitHub. Ils sont plus faciles à imaginer comme le dossier d'un projet. Un référentiel contient tous les fichiers du projet (y compris la documentation) et stocke l'historique des révisions de chaque fichier. Les référentiels peuvent avoir plusieurs collaborateurs et peuvent être publics ou privés.

Un projet tel que documenté sur GitHub:

Les tableaux de projets sur GitHub vous aident à organiser et à prioriser votre travail. Vous pouvez créer des tableaux de projets pour des fonctionnalités spécifiques, des feuilles de route complètes ou même des listes de contrôle de publication. Avec les tableaux de projets, vous avez la possibilité de créer des flux de travail personnalisés qui répondent à vos besoins.

Une partie de la confusion est que la nouvelle fonctionnalité, Projets, entre en conflit avec l'utilisation surchargée du terme projet dans la documentation ci-dessus.

Fait 1: les projets et les référentiels étaient toujours des synonymes sur GitHub.

Fait 2: Ce n'est plus le cas.

Il y a beaucoup de confusion sur les référentiels et les projets. Dans le passé, les deux termes étaient utilisés à peu près de manière interchangeable par les utilisateurs et par la propre documentation du GitHub. Cela se reflète dans certaines des réponses et des commentaires ici qui expliquent les différences subtiles entre ces termes et le moment où l'un a été préféré à l'autre. La différence était toujours subtile, par exemple, comme le suivi des problèmes faisant partie du projet mais ne faisant pas partie du référentiel qui pourrait être considéré comme une chose strictement git, etc.

Plus maintenant.

Actuellement, les dépôts et les projets font référence à différents types d'entités qui ont des API séparées :

• https://developer.github.com/v3/repos/
• https://developer.github.com/v3/projects/

Depuis lors, il n'est plus correct d'appeler le repo un projet ou vice versa. Notez qu'il est souvent confondu dans la documentation officielle et qu'il est dommage qu'un terme déjà largement utilisé ait été choisi comme nom de la nouvelle entité mais c'est le cas et il faut vivre avec ça.

La conséquence est que les dépôts et les projets sont généralement confus et chaque fois que vous lisez des projets GitHub, vous devez vous demander s'il s'agit vraiment des projets ou des dépôts. S'ils avaient choisi un autre nom ou une abréviation comme "proj", alors nous pourrions savoir que ce qui est discuté est le nouveau type d'entité, un objet précis avec des propriétés concrètes, ou un genre de chose projectish de type repo.

Le terme généralement sans ambiguïté est «conseil de projet» .

Que pouvons-nous apprendre de l'API

Le premier point de terminaison dans la documentation de l'API Projects:

• https://developer.github.com/v3/projects/#list-repository-projects

est décrit comme suit : Liste des projets de référentiel . Cela signifie qu'un référentiel peut avoir de nombreux projets. Donc, ces deux-là ne peuvent pas signifier la même chose. Il inclut la réponse si les projets sont désactivés :

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

ce qui signifie que certains dépôts peuvent avoir des projets désactivés. Encore une fois, ce ne peut pas être la même chose lorsqu'un dépôt peut avoir des projets désactivés.

Il existe d'autres points de terminaison intéressants:

• Créer un projet de référentiel -POST /repos/:owner/:repo/projects
• Créer un projet d'organisation -POST /orgs/:org/projects

mais il n'y a pas :

• Créer un projet utilisateur -POST /users/:user/projects

Ce qui nous amène à une autre différence:

1. Les référentiels peuvent appartenir à des utilisateurs ou à des organisations
2. Les projets peuvent appartenir à des référentiels ou à des organisations

ou, plus important encore:

1. Les projets peuvent appartenir à des référentiels mais pas l'inverse
2. Les projets peuvent appartenir à des organisations mais pas à des utilisateurs
3. Les référentiels peuvent appartenir à des organisations et à des utilisateurs

Voir également:

• https://help.github.com/articles/about-project-boards/

Je sais que c'est déroutant. J'ai essayé de l'expliquer aussi précisément que possible.

Les référentiels GitHub sont utilisés pour stocker tous les fichiers, dossiers et autres ressources qui vous intéressent.

Projet Git: C'est également l'une des ressources du référentiel Git et son utilisation principale est de gérer les projets avec un tableau visuel. Si vous créez un projet dans le référentiel Git, il crée un tableau visuel comme un tableau Kanban pour gérer le projet.

De cette façon, vous pouvez avoir plusieurs projets dans un référentiel.

En général, sur GitHub, 1 référentiel = 1 projet . Par exemple: https://github.com/spring-projects/spring-boot . Mais ce n'est pas une règle stricte.

1 référentiel = plusieurs projets . Par exemple: https://github.com/donhuvy/java_examples

1 projets = plusieurs référentiels . Par exemple: https://github.com/zendframework/zendframework (1 projet nommé Zend Framework 3 a 61 + 1 = 62 référentiels, ne croyez pas? Comptons les modules de Zend Frameworks + le référentiel principal)

Je suis totalement d' accord avec @Brandon Ibbotson de commentaire :

Un référentiel GitHub est juste un "répertoire" où des dossiers et des fichiers peuvent exister.

En ce qui concerne le vocabulaire git, un projet est le dossier dans lequel se trouve le contenu réel (fichiers). Tandis que Repository (repo) est le dossier dans lequel git garde l'enregistrement de chaque modification apportée dans le dossier du projet . Mais dans un sens général, ces deux peuvent être considérés comme identiques. Projet = Référentiel

La différence conceptuelle dans ma compréhension est qu'un projet peut contenir de nombreux dépôts et qui sont indépendants les uns des autres, alors que simultanément un dépôt peut contenir de nombreux projets. Le dépôt n'est qu'un lieu de stockage pour le code, tandis qu'un projet est un ensemble de tâches pour une certaine fonctionnalité.

Cela a-t-il du sens? Un grand dépôt peut avoir de nombreux projets en cours de travail par différentes personnes en même temps (beaucoup de fonctionnalités de différence étant ajoutées à un monolithe), un grand projet peut avoir de nombreux petits dépôts séparés mais faisant partie du même projet qui interagissent avec chacun autre - microservices? C'est une vision personnelle de ce que vous voulez faire. Je pense que le repo (stockage) vs projet (tâches) est la principale différence - si je me trompe, veuillez me le faire savoir / expliquer! Merci.

C'est ma compréhension personnelle du sujet.

Pour un projet, nous pouvons faire le contrôle de version par différents référentiels. Et pour un référentiel, il peut gérer un projet entier ou une partie de projets.

Concernant votre projet (plusieurs applications prototypes indépendantes de chacune d'elles). Vous pouvez gérer le projet par un référentiel ou par plusieurs référentiels, la différence:

1. Gérer par un référentiel. Si l'une des applications est modifiée, l'ensemble du projet (toutes les applications) sera engagé dans une nouvelle version.

2. Gérer par plusieurs référentiels. Si une application est modifiée, cela n'affectera que le référentiel qui gère l'application. La version des autres référentiels n'a pas été modifiée.