Qu’est-ce qu’un bon flux de travail pour les fourches submodules

Question

Supposons que nous avons les éléments suivants structure du dépôt sur github:

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

Un développeur dans mon entreprise, les fourches de la société de projet, prise de son espace de travail ressemble à ceci:

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

C'est très bien pour 90% des développeurs puisqu'ils ne changent pas le sous-module de la bibliothèque, ils ne fonctionnent que dans le projet. Maintenant, supposons qu'il y a une nouvelle fonctionnalité qui nécessite des améliorations dans le sous-module. Le développeur chargé de cette convertit son espace de travail, pour cela:

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

Y arriver n'est pas anodin puisqu'il doit remplacer un submdule avec un autre sous-module (git, l'original et la fourche de la sous-module sont deux choses différentes).

Si ce développeur travaille sur la bibliothèque pour un peu plus de temps, il commet cette structure à son maître de la branche, de sorte que son fork sur github utilise toujours la fourche sous-module.

Une fois qu'il est prêt avec le développement, il va créer une pull request. Le problème est que lors de la fusion de la demande d'extraction le principal référentiel ressemblera à ceci:

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

Ceci est problématique car maintenant chaque développeur qui suit la direction de la société va se retrouver avec le développeur du sous-module.

Pour contourner ce problème, avant que le développeur fait une demande d'extraction, son maître de la branche devraient être retournés à la société:sous-module.git - ce qui est juste très maladroit, surtout depuis que localement il va toujours encore envie de travailler avec développeur:sous-module.git.

Nous avons essayé plusieurs flux de travail, et le problème ci-dessus est la seule où nous n'avons pas un bon flux de travail encore.

Answer 1

Lorsque le développeur crée un commit avec le sous-module à une version particulière, c'est une déclaration forte que le supermodule fonctionne avec le sous-module à cette version exacte. Si son code en fait de travailler avec la compagnie de la version de la sous-module, je pense que la bonne chose à faire est que le développeur:

1. la direction de l'supermodule
2. la caisse de la société de version dans le sous-module
3. mise à jour de .gitmodules dans le supermodule, si le développeur a changé qu'à partir de la version amont
4. scène et s'engager à ce que le changement
5. tout tester
6. question pull request

Il peut alors revenir à son développement normal de la branche dans le supermodule.

Une chose que je ne comprends pas au sujet de votre question est la suivante:

Y arriver n'est pas anodin puisqu'il doit remplacer un submdule avec un autre sous-module (git, l'original et la fourche de la sous-module sont deux choses différentes).

Au contraire, le sous-module peut être n'importe quel dépôt git tant qu'il contient le commit qui le supermodule points. Si il existe deux types de dépôts distants, il suffit d'ajouter une distance supplémentaire dans le sous-module. (Le développeur doit variation .gitmodules ainsi si ils vont partager leur dépôt avec quelqu'un d'autre.)

---

En réponse à votre commentaire ci-dessous, c'est peut-être la peine d'aller à travers la façon de passer d'un sous-module de pointage d'une version à l'autre. Supposons que le développeur est à l'aide de leurs propres dépôts pour le super et le sous-module, mais ceux qui sont à la fois cloné à partir de la société versions (à savoir, pour la plupart de l'histoire est la même), et le sous-module est sur le chemin de lib. Le développeur veut maintenant basculer le sous-module de point à la société de la version à la place. Ils peuvent faire ce qui suit:

1. Modifier l' url paramètre pour le sous-module en .gitmodules pour pointer vers la société du référentiel.
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 être simplement changé d' git checkout <whatever> une fois la distance et de la direction générale sont mis en place.

Answer 2

Une autre solution simple est de dire git d’ignorer .gitmodules et de les supprimer du suivi. Comme dit ci-dessus, .gitmodules sont utilisés uniquement pour l’initialisation des sous-modules, il est donc nécessaire qu’une seule fois, lors de la vérification des sous-modules.

Answer 3

Pour lui de développer sur elle, le dev n'a pas besoin de modifier le sous-module lui-même - ils pu ajouter un autre à distance et de le pousser à.

Exemple:

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

Flux de travail:

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

// hack sur le projet

cd path/to/submodule
git push developer branchname

Ce n'est certainement pas parfait et peut causer des problèmes si un pull request sur le développeur de projet/rend à société/projet avant de développeur/sous-module permet à l'entreprise/sous-module.

Juste mes réflexions rapides.