Comment gérer la hiérarchie de twigs git

J'ai un repository git, avec la twig master qui est la principale.

J'ai une hiérarchie de la manière suivante:

  master | core / | \ V100 V200 V300 

V100 , V200 , V300 sont différents modules qui dépendent du kernel.

Plusieurs personnes travailleront sur ces modules et modifieront également le module de core de l'une des twigs V* .

Le problème est que je ne sais pas vraiment comment gérer cette situation sans copyr les files, en changeant la twig principale, en la modifiant, puis en tirant les changements des twigs V* .

Y a-t-il une meilleure façon de gérer ces changements? Ou le module de base ne devrait-il jamais être modifié à partir d'une twig V* ?

Remarque: Le module core ne peut pas être testé de manière autonome, il contient uniquement des classs abstraites, des interfaces et des bibliothèques utilisées dans les autres twigs.

Solutions Collecting From Web of "Comment gérer la hiérarchie de twigs git"

On dirait que vous avez confondu twigment avec un moyen de maintenir différents modules. Les twigs doivent être des versions du même code.

Par exemple, vous pouvez avoir un master, un développement et plusieurs twigs de fonctionnalités. Votre twig maîtresse est le code que vous avez déployé. Votre twig de développement peut être le code que vous préparez pour le deployment. Et vos twigs de fonctionnalité sont vos nouvelles fonctionnalités inachevées.

Lorsque vous terminez une fonctionnalité, vous fusionnez sa twig dans la twig de développement. Une fois que votre version est prête, vous fusionnez votre twig de développement en master et libérez votre code. Et ainsi de suite ça va comme un cycle.

Généralement, je trouve qu'il est préférable de conserver des groupes de code distincts dans des référentiels distincts. Donc, il me semble que vous voudriez un repo pour chacun de vos modules V *. Vous auriez également un repo pour le module de base. En git, il est courant d'avoir beaucoup de repos comme ça.

En option, vous pouvez inclure le module Core dans les autres repos en tant que sous-module. Qu'est-ce que vous faites est de créer un directory dans votre module principal, par exemple V100 / core, puis définissez-le comme un sous-module. Cela renvoie alors à une validation spécifique du repo Core. De cette façon, vous pouvez être certain que vos projets sont liés à une version du sous-module qui leur convient.

Les sous-modules ont des subtilités et des pièges, et à cause de cela ils ont un mauvais nom. Je trouve que lorsqu'ils sont utilisés correctement, ils fonctionnent très bien. Pour en savoir plus sur eux, consultez http://git-scm.com/book/en/Git-Tools-Submodules