Dépôts Git simples ou multiples pour les bibliothèques partagées entre les équipes

Question

Je regarde comment/si je devrais passer de svn à git. J'ai actuellement un ensemble multicouche de projets dans svn qui sont en couches tel que D utilise C qui utilise B qui utilise A. Les projets déployés réels comme X, Y, Z utilisent l'une des bibliothèques communes A-D. L'objectif est que les projets futurs et les autres équipes partagent les bibliothèques de base (A-D) et permettent un meilleur contrôle des branches. En svn, si nous souhaitons permettre à d'autres équipes d'utiliser la bibliothèque C sans impliquer X, Y, Z alors c'est simple, elles vérifient simplement le bit C de l'arbre svn, si cela leur permet de vouloir patch B, puis idem. Ils ne touchent jamais X, Y, Z même s'ils sont dans le même repo. Ce n'est pas si évident ce qui se passe avec git.

Si je souhaite configurer quelque chose en utilisant git, comment suggéreriez-vous que je le configure et quels sont les avantages et les inconvénients de votre configuration suggérée.

Caractéristiques Je cherche sont:

1. marquage simple (si possible) peut donc marquer l'état de l'ensemble codebase facilement (simple avec une racine svn commune ou un git unique)
2. facile pour les autres à intégrer/réutiliser les bibliothèques communes AD
3. Simple pour eux de nous renvoyer des correctifs/correctifs suggérés que nous pouvons choisir de prendre ou d'ignorer (l'une des principales choses que je veux de git).
4. Les équipes d'avoir efficacement les caractéristiques de la propriété privée disponibles pour les bibliothèques partagées (afin qu'ils puissent les étiqueter et les fixer pour eux-mêmes sur leurs propres échéances)

Git semble offrir ce que je veux, je ne suis pas sûr comment pour faire face au problème de repos unique ou multiple.

Answer 1

Si je veux mettre quelque chose en utilisant git, comment proposeriez-vous je l'ai mis en place [...]

Il suffit d'aller avec plusieurs dépôts git (ils sont tout à fait pas cher et ils sont semblables à beaucoup de petits bateaux au lieu d'un Titanic - en d'autres termes, je trouve qu'ils sont flexibles et j'aime la flexibilité).

Maintenant, puis-je aider un projet qui est structuré comme si

foo/server 
foo/client 
foo/docs 
foo/tools/ 

Le « serveur », « client », « docs » et chaque dossier dans les « outils » sont des référentiels git séparés. Cela permet aux membres de l'équipe spécialisée de cloner et de travailler sur exactement ce qu'ils souhaitent travailler. Sans compter que, si nous voulons juste tout rentrer, nous pouvons cloner foo (ce qui tire dans le reste comme des sous-modules).

C'est génial que git vous permette de le faire alors pourquoi ne pas en profiter?

[...] et ce sont les Upsides/inconvénients avec votre configuration suggéré.

Il est possible que ma suggestion soit légèrement complexe à implémenter.