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

Question

Une des choses que j'aime au sujet de la façon dont je l'ai Subversion est que je puisse avoir un seul référentiel principal avec de multiples projets. Quand je veux travailler sur un projet, je peux découvrez juste que projet. Comme ceci

\main
    \ProductA
    \ProductB
    \Shared

alors

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

En tant que nouvel utilisateur de git j'ai envie d'explorer un peu des meilleures pratiques dans le domaine avant de s'engager à un flux de travail spécifique. De ce que j'ai lu jusqu'à présent, git stocke tout dans un seul .git dossier à la racine de l'arborescence du projet. J'ai donc pu faire une de deux choses.

1. Définir un projet distinct pour chaque Produit.
2. Mettre en place un seul projet d'envergure et stocker les produits dans des sous-dossiers.

Il y a des dépendances entre les produits, de sorte que le seul projet d'envergure semble le plus approprié. Nous allons utiliser un serveur où tous les développeurs peuvent partager leur code. J'ai déjà eu ce travail sur SSH ET HTTP et que la partie que j'aime. Cependant, les dépôts SVN sont déjà plusieurs GO en taille, donc en faisant glisser autour de l'ensemble du référentiel sur chaque machine semble être une mauvaise idée, surtout depuis que nous sommes facturées excessive de la bande passante du réseau.

J'imagine que le projet du noyau Linux référentiels sont aussi grande donc il y a une bonne façon de gérer cela avec Git, mais je n'en ai pas compris encore.

Existe-il des lignes directrices ou des pratiques optimales pour travailler avec de très grandes multi-projet de référentiels?

Answer 1

La ligne directrice est simple, en ce qui concerne Git limites:

• un repo par projet
• un projet principal avec submodules.

L'idée est de ne pas stocker le tout dans un géant de repo git, mais la construction d'un petit repo comme un projet principal, qui fait référence au droit commet d'autres repos, chacune représentant un projet ou d'un composant commun de ses propres.

---

L' OP Paul Alexander commentaires:

Cela semble similaire à la "alias" soutien fourni par la subversion.
Nous avons essayé et trouvé ça très lourd à mettre constamment à jour la version de références dans les externes étant donné que les projets sont développés simultanément avec dépendances sur uns des autres. Est-il une autre option??

@Paul: oui, au lieu de la mise à jour de la version du projet principal, vous pouvez soit:

• développer vos projets directement dans le projet principal (comme expliqué dans "la Vraie Nature des submodules"),
• ou vous de référence dans un sous-repo un origin vers le même sous-pensions être développé ailleurs: à partir de là il vous suffit de tirer à partir de ce sous-repo les modifications apportées ailleurs.

Dans les deux cas, vous devez ne pas oublier de commettre le projet principal, pour enregistrer la nouvelle configuration. Pas de "externe" de la propriété de mise à jour ici. Tous les processus est beaucoup plus naturel.

Honnêtement, cela sonne comme une vraie douleur et tout ce qui oblige les développeurs à faire quelque chose manuellement à chaque fois va juste être une source régulière de bugs d'un entretien.
Je suppose que je vais regarder dans l'automatisation de ce avec certains scripts dans le super projet.

Je lui ai répondu:

Honnêtement, vous avez peut-être raison... c'est jusqu'à la dernière Git version 1.7.1.
git diff et git status tous les deux appris à prendre en compte submodules les états, même si elle est exécutée à partir du projet principal.
À ne pas manquer sous-module de modification.

Cela étant dit:

• submodules sont différents de SVN alias: voir "Pourquoi submodules incompatible avec svn externes?"
• la gestion des submodules peut être délicat: voir "Comment fonctionne exactement git sous-module de travail?".