Flux de travail Git pour plusieurs équipes

Nous allons commencer à utiliser Git (pas encore) et je veux définir le workflow.

Nous avons 4 équipes réparties sur 4 sites mondiaux différents, développant ensemble le même produit. Chaque équipe possède une partie du code du produit, mais parfois elle doit également apporter des modifications au code appartenant à d'autres équipes.

Existe-t-il une recommandation pour un workflow Git pour un tel environnement?

J'ai déjà vu cet article , mais l'approche ici est "nous créons des branches supplémentaires aussi rarement que possible", et je crois davantage à l'approche "branche pour chaque user story".

En outre, cet article présente une belle approche.

J'avais en tête d'avoir une branche master, une branche permanente par équipe fusionnant périodiquement en master et une branche par user-story fusionnant avec les branches des équipes. Est-ce que cela a du sens, ou cela ne fonctionnerait pas?

git version-control

— Igor Oks
source

Nous utilisons ce modèle de branchement , mais je pense que si vous lisez "branche de fonctionnalité" comme "branche d'histoire", cela correspond très bien à votre deuxième article.

Je suis sûr que 10 personnes pourraient y répondre avec 10 réponses différentes. Voici ce qui fonctionne pour moi: nous avons un référentiel maître hébergé sur github qui dénote la version «actuelle». Les versions plus anciennes sont ramifiées (bien que le marquage fonctionne également). Les membres de l'équipe sont encouragés à créer des branches pour les tâches sur lesquelles ils travaillent. Une fois terminé, ils font une demande d'extraction au maître (ou partout où il doit fusionner), puis quelqu'un d'autre examine la demande d'extraction et est responsable de la fusionner en maître. Ils sont également chargés de nettoyer la succursale une fois celle-ci fusionnée.

Vous pourriez être intéressé par les sous-modules pour séparer les bases de code des différentes équipes. Ils peuvent ensuite bifurquer les bases de code les uns des autres et envoyer des correctifs lors de la modification des parties du code les uns des autres.

— Fred Foo

@larsmans & carbonbasednerd - Vos commentaires auraient dû être des réponses, ils auraient obtenu des votes positifs de ma part. * 8 ')

— Mark Booth

Réponses:

Jetez un œil à Successful Git Branching Model , qui a une belle stratégie de branchement pour le développement de fonctionnalités à travers les versions.

Un modèle de branchement git réussi

Vous pouvez implémenter quelque chose de similaire avec un niveau supplémentaire pour les branches d'équipe entre la branche «développer» et les «branches fonctionnelles». Le fait d'avoir des branches d'équipe permettrait également à deux équipes de collaborer plus efficacement en fusionnant leurs branches d'équipe.

— Nick Haddad
source

Je dirais que chaque équipe a sa propre version du référentiel, avec un référentiel global où tout le monde s'engage (comme dans le noyau Linux, où le référentiel Linus EST le noyau et le référentiel central).

Ensuite, pour maintenir le code produit, vous pouvez utiliser des sous-modules comme @larsmans l'a dit, puis chaque équipe ne peut travailler principalement que sur la partie qui est la plus importante pour elle et si elle a besoin de travailler avec une autre partie, elle peut le faire, mais elle devra se rappeler de mettre à jour le sous-module, et c'est là que réside le problème (car il est très facile de se tromper en utilisant git, heureusement, il est également facile de s'en éloigner).

Mais comme vos équipes sont habituées à cela et savent qu'elles changent d'autres codes d'équipe, il est plus facile pour elles de se rappeler de faire la mise à jour du sous-module, avant de changer un module étranger.

— Coyote21
source