Qu’est-ce qu’un bon workflow pour les fourches de sous-modules

Supposons que nous ayons la structure de référentiel suivante sur github:

company:project.git \- company:submodule.git 

Un développeur de mon entreprise crée le projet de la société, faisant ressembler son espace de travail à ceci:

 developer:project.git \- company:submodule.git 

Cela convient à 90% des développeurs car ils ne modifient pas la bibliothèque de sous-modules, ils ne fonctionnent que dans le projet. Supposons maintenant qu’une nouvelle fonctionnalité nécessite des améliorations dans le sous-module. Le développeur chargé de cela convertit son espace de travail en ceci:

 developer:project.git \- developer:submodule.git 

S’y rendre n’est pas anodin car il doit remplacer un sous-module par un autre sous-module (pour git, l’original et le fork du sous-module sont deux choses différentes).

Si ce développeur travaille un peu plus longtemps sur la bibliothèque, il valide cette structure sur sa twig principale, donc son fork sur github utilise toujours le sous-module forked.

Une fois qu’il sera prêt au développement, il créera une demande de tirage. Le problème est que lors de la fusion de la requête d’extraction, le référentiel principal ressemblera à ceci:

 company:project.git \- developer:submodule.git 

Cela pose problème car tous les développeurs qui suivent la twig de l’entreprise se retrouvent avec le sous-module du développeur.

Pour résoudre le problème, avant que le développeur ne fasse une requête, sa twig principale devrait être renvoyée à la société: submodule.git – ce qui est très gênant, surtout que localement, il voudra toujours travailler avec developer: submodule. git.

Nous avons essayé plusieurs workflows et le problème ci-dessus est le seul où nous n’avons pas encore un bon workflow.

Lorsque le développeur crée une validation avec le sous-module à une version particulière, cela signifie que le supermodule fonctionne avec le sous-module à cette version exacte. Si son code fonctionne réellement avec la version du sous-module de la société, je pense que la bonne chose à faire pour le développeur est de:

  1. twigz le supermodule
  2. vérifier la version de l’entreprise dans le sous-module
  3. mettre à jour les .gitmodules dans le supermodule, si le développeur a changé cela depuis la version amont
  4. mettre en scène et commettre ce changement
  5. tout tester
  6. émettre la demande de tirage

Il peut alors revenir à sa twig de développement normale dans le supermodule.

Une chose que je ne comprends pas sur votre question est la suivante:

S’y rendre n’est pas anodin car il doit remplacer un sous-module par un autre sous-module (pour git, l’original et le fork du sous-module sont deux choses différentes).

Au contraire, le sous-module peut être n’importe quel repository git, à condition qu’il contienne la validation pointée par le supermodule. S’il existe deux référentiels distants différents, il lui suffit d’append une télécommande supplémentaire dans le sous-module. (Le développeur doit également changer les .gitmodules s’ils veulent partager leur repository avec qui que ce soit.)


En réponse à votre commentaire ci-dessous, il vaut peut-être la peine de passer en revue la manière de faire basculer un sous-module vers une version vers une autre. Supposons que le développeur utilise ses propres référentiels pour le super et le sous-module, mais ceux-ci sont tous deux clonés à partir des versions de l’entreprise (c.-à-d. Le développeur veut maintenant changer de sous-module pour indiquer la version de l’entreprise. Ils peuvent faire ce qui suit:

  1. Modifiez le paramètre url du sous-module dans les modules .gitmodules pour qu’il pointe vers le référentiel de l’entreprise.
  2. cd lib
  3. git remote add company developer@company:/srv/git/lib.git
  4. git fetch company
  5. git checkout -b upstream-master company/master
  6. cd ..
  7. git add .gitmodules lib
  8. git commit -m "Switch the lib submodule to point back to the company's version"

Les étapes 3 à 5 peuvent simplement être changées pour ” git checkout la configuration de la télécommande et de la twig.

Une autre solution simple consiste à dire à git d’ignorer les modules .git et de les supprimer du suivi. Comme indiqué plus haut, les modules .git ne sont utilisés que pour l’initialisation des sous-modules, il n’est donc nécessaire qu’une seule fois, lors de la vérification des sous-modules.

Pour qu’il y développe, le développeur n’a pas besoin de changer le sous-module lui-même – ils pourraient append une autre télécommande et la pousser.

Exemple:

 developer:project.git \- company:submodule.git Origins: company/submodule.git developer/submodule.git 

Workflow:

 cd path/to/submodule git remote add developer git@gitserver/developer/submodule.git 

// pirater le projet

 cd path/to/submodule git push developer branchname 

Ce n’est certainement pas parfait et peut causer des problèmes si une demande d’extraction sur le développeur / projet est envoyée à l’entreprise / au projet avant que le développeur / sous-module ne soit intégré à la société / au sous-module.

Juste mes pensées rapides.

Supposons maintenant qu’une nouvelle fonctionnalité nécessite des améliorations dans le sous-module.

La consortingbution étant faite dans le sous-module, seuls les commits du sous-module git repo doivent être demandés, comme d’habitude.

Pour pousser sur votre fourche de sous-module,

  • le projet .gitmodules config peut être modifié dans votre fourchette clonée (mais est conservé de votre côté)
  • ou votre fourche de sous-module peut être ajoutée en tant que télécommande