IP Girl
  1. IP Girl
  3. Disposition du référentiel GIT pour serveur avec plusieurs projets
Intereting Posts
Exception à la masortingce ne se décompose pas en un pointeur? Quelle est la différence entre l’opérateur point (.) Et -> en C ++? comment envoyer la sortie du module pprint à un fichier journal Quelles devraient être les valeurs de GOPATH et GOROOT? Comment enregistrer SMS dans la boîte de réception dans Android? MySQL: Convertir INT en DATETIME Que signifie `: location =>…` et `head: ok` dans la déclaration de format ‘respond_to’? Boîte de dialog LocationSettingsRequest pour activer le GPS – onActivityResult () ignoré Comment centrer horizontalement div à l’intérieur du div parent Requête de limite / décalage de mongo et compte Rails 3 exécute une requête SQL personnalisée sans modèle Comment changer le style de bordure de la case à cocher en CSS? Lire les emails (depuis gmail) dans emacs 24 Comment installer le plugin pour Eclipse à partir de .zip XPath: sélectionne les éléments enfants qui * n’ont pas * un nom spécifique

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

L’une des choses que j’aime dans la façon dont Subversion est configuré est que je peux avoir un seul référentiel principal avec plusieurs projets. Quand je veux travailler sur un projet, je peux simplement vérifier 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 ce domaine avant de m’engager dans un workflow 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 l’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 y a des dépendances entre les produits, donc le seul projet massif semble approprié. Nous utiliserons un serveur où tous les développeurs pourront partager leur code. Je travaille déjà sur SSH & HTTP et ce que j’aime beaucoup. Cependant, les référentiels de SVN ont déjà une taille de plusieurs Go, ce qui semble être une mauvaise idée de faire le tour de tout le référentiel sur chaque machine, d’autant plus que la bande passante du réseau est trop élevée.

J’imagine que les référentiels de projets du kernel Linux sont également volumineux, il doit donc y avoir une manière appropriée de gérer cela avec Git, mais je ne l’ai pas encore trouvé.

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

La ligne direcsortingce est simple, en ce qui concerne les limites de Git :

  • un repo par projet
  • un projet principal avec des sous-modules .

L’idée n’est pas de tout stocker en un seul repository géant, mais de créer un petit repository en tant que projet principal, qui référencera les bons commits des autres repos, chacun représentant un projet ou un composant commun.

L’ OP Paul Alexander commente :

Cela ressemble au support “externe” fourni par Subversion.
Nous avons essayé ceci et avons trouvé extrêmement fastidieux de mettre constamment à jour les références de version dans les externes car les projets sont développés en même temps que les dépendances les unes par rapport aux autres. Y a-t-il une autre option?

@ Paul: oui, au lieu de mettre à jour la version du projet principal, vous avez 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 à une origin vers le même sous-repo en cours de développement ailleurs: de là vous n’avez plus qu’à tirer de ce sous-repo les modifications apscopes 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. Tout le processus est beaucoup plus naturel.

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

J’ai répondu:

Honnêtement, vous avez peut-être eu raison … c’est jusqu’à la dernière version 1.7.1 de Git .
git diff et git status tous deux appris à prendre en compte les états des sous-modules même s’ils étaient 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 svn externals? ”
  • la gestion des sous-modules peut être délicate: voir ” Comment fonctionne exactement le sous-module git? “.

GitSlave vous permet de gérer plusieurs repos indépendants comme un seul. Chaque repo peut être manipulé par des commandes régulières git, tandis que gitslave vous permet de lancer une commande supplémentaire sur tous les repos. 

 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 en termes de composants et de versions simplifiées avec des outils tels que Maven. La mise en pension par projet ajoute une protection en limitant la scope de ce que le développeur modifie – en termes de commits erronés.