Christopher a très bien énuméré les inconvénients d'un modèle à un projet par dépôt. J'aimerais discuter de certaines des raisons pour lesquelles vous pourriez envisager une approche à référentiel multiple. Dans de nombreux environnements dans lesquels j'ai travaillé, une approche multi-référentiels constituait une solution raisonnable, mais il n’était pas toujours facile de décider du nombre de référentiels à disposer et du lieu où opérer les réductions.
Dans mon poste actuel, j'ai migré un énorme dépôt CVS avec un dépôt unique avec plus de dix ans d’histoire dans un certain nombre de dépôts git. Depuis cette décision initiale, le nombre de référentiels a augmenté (grâce aux actions d'autres équipes), au point que je soupçonne que nous en avons plus que ce qui serait optimal. Certains nouveaux employés ont suggéré de fusionner les référentiels, mais j’ai plaidé contre. Le projet Wayland a une expérience similaire. Dans une conversation que j'ai récemment vue, ils avaient, à un moment donné, plus de 200 dépôts git, pour lesquels le responsable s'est excusé. En regardant leur site Web , je vois maintenant qu'ils sont à 5 heures, ce qui semble raisonnable. Il est important de noter que la jonction et la division de référentiels est une tâche gérable, et qu'il est acceptable d'expérimenter (dans des limites raisonnables).
Alors, quand voulez-vous plusieurs référentiels?
- Un seul référentiel serait trop volumineux pour être efficace.
- Vos référentiels sont faiblement couplés ou découplés.
- Un développeur n'a généralement besoin que d'un ou d'un petit sous-ensemble de ses référentiels à développer.
- Vous souhaitez généralement développer les référentiels de manière indépendante et ne les synchroniser que de temps en temps.
- Vous voulez encourager plus de modularité.
- Différentes équipes travaillent sur différents référentiels.
Les points 2 et 3 ne sont significatifs que si le point 1 tient. En scindant nos référentiels, j'ai considérablement réduit les délais de nos collègues hors site, réduit la consommation de disques et amélioré le trafic réseau.
4 et 5 sont plus subtiles. Lorsque vous séparez les dépôts d'un client et d'un serveur, cela rend plus onéreuse la coordination des modifications entre le code client et le code serveur. Cela peut être positif car cela encourage une interface découplée entre les deux.
Même avec les inconvénients des projets multi-référentiels, de nombreux travaux respectables sont effectués de cette manière - on pense à Wayland et à boost. Je ne crois pas qu'un consensus sur les meilleures pratiques ait encore évolué et qu'il faut faire preuve de jugement. Des outils permettant de travailler avec plusieurs référentiels (git-sous-arbre, git-sous-module et autres) sont encore en cours de développement et d'expérimentation. Mon conseil est d'expérimenter et d'être pragmatique.