Disposition du référentiel GIT pour le serveur avec plusieurs projets

Une des choses que j'aime dans la façon dont j'ai configuré Subversion est que je peux avoir un seul référentiel principal avec plusieurs projets. Lorsque je veux travailler sur un projet, je peux vérifier uniquement ce projet. Comme ça

\main
    \ProductA
    \ProductB
    \Shared

puis

svn checkout http://.../main/ProductA

En tant que nouvel utilisateur de git, je souhaite explorer un peu les meilleures pratiques dans le domaine avant de m'engager dans un flux de travail spécifique. D'après ce que j'ai lu jusqu'à présent, git stocke tout dans un seul dossier .git à la racine de l'arborescence du projet. Donc je pourrais faire une des deux choses.

1. Configurez un projet distinct pour chaque produit.
2. Configurez un seul projet massif et stockez les produits dans des sous-dossiers.

Il existe des dépendances entre les produits, de sorte que le projet unique et massif semble approprié. Nous utiliserons un serveur sur lequel tous les développeurs pourront partager leur code. Cela fonctionne déjà sur SSH et HTTP et cette partie que j'aime. Cependant, les référentiels dans SVN ont déjà une taille de plusieurs Go, donc traîner tout le référentiel sur chaque machine semble être une mauvaise idée - d'autant plus que nous sommes facturés pour une bande passante réseau excessive.

J'imagine que les référentiels de projet du noyau Linux sont tout aussi volumineux, il doit donc y avoir un moyen approprié de gérer cela avec Git, mais je ne l'ai tout simplement pas encore compris.

Existe-t-il des directives ou des meilleures pratiques pour travailler avec de très grands référentiels multi-projets?

Le guide est simple, en ce qui concerne les limites de Git :

• un dépôt par projet
• un projet principal avec des sous-modules .

L'idée n'est pas de tout stocker dans un seul dépôt git géant, mais de construire un petit dépôt en tant que projet principal, qui référencera les bons commits d'autres dépôts, chacun représentant un projet ou un composant commun qui lui est propre.

L' OP Paul Alexander commente :

Cela ressemble au support "externe" fourni par subversion.
Nous avons essayé cela et avons trouvé extrêmement fastidieux de constamment mettre à jour les références de version dans les externes, car les projets sont développés simultanément avec des dépendances les uns sur les autres. Y a-t-il une autre option ??

@Paul: oui, au lieu de mettre à jour la version depuis le projet principal, vous pouvez soit:

• développer vos sous-projets directement à partir du projet principal (comme expliqué dans "La vraie nature des sous-modules "),
• ou vous faites référence dans un sous-repo et originvers le même sous-repo en cours de développement ailleurs: à partir de là, il vous suffit d'extraire de ce sous-repo les modifications apportées ailleurs.

Dans les deux cas, il ne faut pas oublier de valider le projet principal, pour enregistrer la nouvelle configuration. Aucune propriété "externe" à mettre à jour ici. Le tout est beaucoup plus naturel.

Honnêtement, cela semble être une vraie douleur et tout ce qui oblige les développeurs à faire quelque chose manuellement à chaque fois sera juste une source régulière de bogues et de maintenance.
Je suppose que je vais chercher à automatiser cela avec quelques scripts dans le super projet.

J'ai répondu:

Honnêtement, vous avez peut-être raison ... c'est-à-dire jusqu'à la dernière version 1.7.1 de Git .
git diffet les git statusdeux ont appris à prendre en compte les états des sous-modules même s'ils sont exécutés à partir du projet principal.
Vous ne pouvez tout simplement pas manquer la modification du sous-module.

Cela étant dit:

• Les sous-modules sont différents des externes SVN: voir " Pourquoi les sous-modules git sont-ils incompatibles avec les externals svn? "
• la gestion des sous-modules peut être délicate: voir " Comment fonctionne exactement le sous-module git? ".

GitSlave vous permet de gérer plusieurs dépôts indépendants en un seul. Chaque dépôt peut être manipulé par des commandes git normales, tandis que gitslave vous permet d'exécuter en plus une commande sur tous les dépôts.

super-repo
+- module-a-repo
+- module-b-repo

gits clone url-super-repo
gits commit -a -m "msg"

Le repo-par-projet présente des avantages avec la mise en composants et des builds simplifiés avec des outils comme Maven. Repo-per-project ajoute une protection en limitant la portée de ce que le développeur est en train de changer - en termes de commits erronés de déchets.