Comment structurer les dépôts git pour le projet?

Je travaille sur un module de synchronisation de contenu pour Drupal. Il existe un module serveur, qui se trouve sur un site Web et expose le contenu via un service Web. Il existe également un module client, qui se trouve sur un site différent et récupère et importe le contenu à intervalles réguliers.

Le serveur est créé sur Drupal 6. Le client est créé sur Drupal 7. Il va y avoir un besoin d'une version Druapl 7 du serveur. Et puis il y aura un besoin d'une version Drupal 8 à la fois du client et du serveur une fois qu'il sera publié l'année prochaine.

Je suis assez nouveau dans le contrôle de git et de source, donc je me demandais quelle est la meilleure façon de configurer les dépôts git? Serait-ce un cas d'avoir un référentiel séparé pour chaque instance, c'est-à-dire:

Drupal 6 server = 1 repository
Drupal 6 client = 1 repository
Drupal 7 server = 1 repository
Drupal 7 client = 1 repository
etc 

Ou serait-il plus logique d'avoir un référentiel pour le serveur et un autre pour le client, puis de créer des branches pour chaque version Drupal?

Actuellement, j'ai 2 référentiels - un pour le client et un autre pour le serveur.

À moins que le projet ne soit vraiment énorme, j'opterais pour un référentiel unique avec des sous-répertoires pour le serveur et le client et créerais une branche pour chaque version. Vous pouvez toujours avoir plusieurs copies du référentiel au cas où vous souhaiteriez accéder à plusieurs versions en même temps.

En gérant plusieurs référentiels, vous rendriez le transfert des modifications plus difficile que nécessaire (le rebasage est plus facile que l'application de correctifs). Dans le cas (improbable), aucune modification ne sera appliquée à plusieurs versions, vous ne perdez toujours rien ...

De plus, vous pouvez toujours basculer vers plusieurs référentiels: il vous suffit de cloner le référentiel et de supprimer les branches dont vous ne voulez pas. Aller dans l'autre sens est plus difficile.

J'opterais pour plusieurs dépôts uniquement si le serveur et le client ne partagent rien ou si le code est vraiment énorme.

J'ai vu et travaillé avec de telles variations. Tout dans un dossier avec des sous-dossiers pour le serveur et le client ou un dépôt chacun. Je préfère le repo unique pour chaque partie principale du projet.

En cas de changements de version importants, je créerais simplement de nouveaux dépôts. Certainement pas de branches différentes pour eux. Bien que les branches soient puissantes pour l'implémentation de nouvelles fonctionnalités et peut-être une branche de déploiement permanente, j'évite toujours d'en avoir trop longtemps en parallèle. Vous devrez toujours les maintenir (faire des rebases lorsque la branche principale a changé, etc.), alors gardez la structure de base aussi simple que possible. Avoir un repo supplémentaire est (à mon humble avis) moins douloureux que de jongler avec des branches dans différents états. Surtout si le client et le serveur ne partagent pas beaucoup de code.

Je ne sais pas grand-chose sur Drupal et à quel point les différences entre les versions sont fortes. Donc, mon point de préférence pour différents référentiels est basé davantage sur mon expérience avec Rails. Entre les versions, il existe parfois de grandes différences dans la façon dont les fichiers sont nommés ou la structure des dossiers (par exemple, le pipeline d'actifs), ce qui facilite la création d'un nouveau référentiel. Drupal (ou tout autre framework) peut avoir moins de différences, alors ce serait bien de continuer dans le repo existant.