Dans GitHub, quelle est la différence conceptuelle entre un projet (pouvant ê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'elles n'explique ce qu'est un projet GitHub, quoi 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 d'utilisation/création de chacun. Par exemple, si j'ai plusieurs prototypes d'applications, tous indépendants les uns des autres, que dois-je créer pour gérer de manière organisée le code source de chacune d'entre elles?
GitHub a récemment introduit une nouvelle fonctionnalité appelée Projects . Ceci fournit un tableau visuel typique de nombreux outils de gestion de projet:
A Repository comme documenté sur GitHub:
Un référentiel est l'élément le plus fondamental de GitHub. Ils sont plus faciles à imaginer en tant que dossier de projet. Un référentiel contient tous les fichiers du projet (y compris la documentation) et stocke l'historique de révision de chaque fichier. Les référentiels peuvent avoir plusieurs collaborateurs et peuvent être publics ou privés.
A Projet comme documenté sur GitHub:
Les tableaux de projet sur GitHub vous aident à organiser et à hiérarchiser votre travail. Vous pouvez créer des tableaux de projet pour des fonctions spécifiques, des feuilles de route complètes ou même des listes de contrôle de publication. Avec les tableaux de projet, 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.
Il y a beaucoup de confusion à propos des dépôts et des projets. Dans le passé, les deux termes étaient utilisés de manière assez interchangeable par les utilisateurs et par la documentation propre du GitHub. Ceci est reflété par certaines des réponses et commentaires 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 si le traqueur de problème faisait partie du projet mais pas du référentiel, ce qui pourrait être considéré comme une chose strictement géniale, etc.
Actuellement, les dépôts et les projets font référence à différents types d'entités qui possèdent des API distinctes :
Depuis lors, il n'est plus correct d'appeler le repo un projet ou inversement. Notez qu'il est souvent confus dans la documentation officielle et qu'il est regrettable qu'un terme déjà largement utilisé ait été choisi comme nom de la nouvelle entité, mais c'est le cas et nous devons vivre avec cela.
La conséquence est que les pensions et les projets sont généralement confondus et chaque fois que vous lisez sur les projets GitHub, vous devez vous demander s'il s'agit vraiment de projets ou de pensions. S'ils avaient choisi un autre nom ou une abréviation du type "proj", nous pourrions alors savoir qu'il s'agit du nouveau type d'entité, d'un objet précis avec des propriétés concrètes, ou d'un type de chose projectish du type repo.
Le terme qui est généralement sans ambiguïté est "panneau de projet" .
Le premier point de terminaison dans la documentation de l'API Projects:
est décrit comme suit: Répertorie les projets de référentiel . Cela signifie qu'un référentiel peut avoir plusieurs projets. Donc, ces deux ne peuvent pas signifier la même chose. Cela inclut 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 projets peuvent avoir des projets désactivés. Encore une fois, cela ne peut pas être la même chose quand un repo peut avoir des projets désactivés.
Il existe d'autres points de terminaison intéressants:
POST /repos/:owner/:repo/projects
POST /orgs/:org/projects
mais il y a non :
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:
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, tel qu'un tableau Kanban, pour gérer le projet.
De cette manière, 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 difficile.
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 contient 61 + 1 = 62 référentiels, ne croyez pas? Laissez compter les modules de Zend Frameworks + le référentiel principal )
Je suis totalement d'accord avec @ Brandon Ibbotson 's comment :
Un référentiel GitHub est juste un "répertoire" dans lequel des dossiers et des fichiers peuvent exister.
En ce qui concerne le vocabulaire git, un Project est le dossier dans lequel le contenu réel (fichiers) réside. Attendu que Repository (repo) est le dossier dans lequel git enregistre toutes les modifications apportées au dossier project . Mais dans un sens général, ces deux aspects peuvent être considérés comme identiques. Projet = Repository
Ceci est ma compréhension personnelle sur le 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 ou plusieurs référentiels, la différence:
Gérer par un référentiel. Si l'une des applications est modifiée, l'ensemble du projet (toutes les applications) sera affecté à une nouvelle version.
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.