Flux de travail Git pour les petites équipes

11

Je travaille sur un workflow git à implémenter dans une petite équipe. Les idées clés du workflow:

  • Il existe un maître de projet partagé auquel tous les membres de l'équipe peuvent écrire
  • Tout le développement se fait exclusivement sur des branches de fonctionnalités
  • Les branches de fonctionnalité sont examinées par un membre de l'équipe autre que l'auteur de la branche
  • La branche de fonctionnalité est finalement fusionnée dans le maître partagé et le cycle recommence

L'article explique en détail les étapes de ce cycle:

https://github.com/janosgyerik/git-workflows-book/blob/small-team-workflow/chapter05.md

Est-ce que cela a du sens ou est-ce que je manque quelque chose?

version-control git teamwork workflows janos
la source

Réponses:

16

J'aime le modèle de branchement git flow . La branche master est laissée seule la plupart du temps, elle ne contient que des releases. La branche de développement doit être stable à tout moment et les branches de fonction peuvent être cassées.

Vous pouvez également combiner cela avec une intégration continue en fusionnant develop dans votre branche de fonctionnalités et votre branche de fonctionnalités dans develop. Bien sûr, vous ne devez fusionner quelque chose en développement que lorsque vous êtes sûr que les choses fonctionnent et ne se cassent pas.

Arjan
la source
Si je comprends bien, le flux git et l'intégration continue sont des méthodes de travail alternatives et ne peuvent pas vraiment être combinés. Dans git flow, le code est fusionné en développement uniquement lorsqu'une fonctionnalité est terminée. Dans une intégration continue, tout le code est fusionné dans une branche partagée au moins une fois par jour, même s'il ne fournit aucune nouvelle fonctionnalité immédiatement.
bdsl
7

Je pense que vous manquez le sujet Intégration continue. Il devrait faire partie de chaque configuration de développement.

Avec les branches de fonctionnalités, vous avez le problème que vous n'intégrez pas en continu, mais uniquement après la fin d'une fonctionnalité.

Si la fonction ramifiée est de courte durée, cela peut être acceptable, mais c'est certainement quelque chose que l'on devrait considérer.

Une autre alternative consiste à configurer les builds CI pour chaque branche de fonctionnalité. Bien sûr, cela aide, mais ce n'est pas l'intégration. Cela devient évident une fois que vous avez trouvé votre premier bogue qui n'apparaît pas dans la fonctionnalité A ou la fonctionnalité B, mais au moment où vous intégrez la fonctionnalité A & B

Une troisième alternative consiste à intégrer la fusion dans une branche d'intégration à la génération CI. Il s'agit d'une véritable intégration, et fonctionne en fait assez bien avec git si le travail est quelque peu séparé, mais provoque des conflits de fusion pendant la génération entraînant des échecs de génération.

Jens Schauder
la source
La branche principale peut être connectée à un CI pour rejeter les fusions de branches de fonction si elles échouent aux tests de non-régression automatisés. Merci pour l'astuce, je vais ajouter une section "Astuces" à la fin et en parler ici.
janos
1
Bien sûr, mais comme dit, ce n'est pas une intégration continue mais une intégration à la fin d'une fonctionnalité qui pourrait être bonne, mais ce n'est pas la même chose
Jens Schauder
1
Je pense que les branches de fonctionnalités sont très utiles, car elles n'ont pas besoin d'être stables. Cela signifie que vous pouvez vous engager fréquemment au lieu d'avoir un énorme commit.
Arjan
Un processus de construction automatisé qui s'exécute selon un calendrier (système CI) est indispensable. Il doit s'exécuter souvent afin que les problèmes de compilation puissent être détectés et résolus rapidement. Les équipes de développement doivent accorder la priorité la plus élevée aux échecs de build. Il est beaucoup plus facile de résoudre ces types de problèmes lors de leur première apparition.
Nathan Pilling
1
Pour nos projets qui utilisent CI (nous avons quelques projets hérités qui ne peuvent pas l'utiliser pour le moment), nous nous engageons TOUT à maîtriser le CI réel, pour nos projets hérités, nous utilisons le modèle de branchement git flow. Les branches de fonctionnalités sont un bloqueur de CI si vous me demandez, elles rendent plus difficile l'intégration CONTINUE (pas seulement une fois terminée). Nous continuons à travailler sur les fonctionnalités et la dernière tâche consiste à l'activer, mais le code est toujours dans le projet.
Elliot Blackburn
1

Vous pouvez vous inspirer de gitflow ou Twgit .

gitflow résume son approche comme suit:

Extensions Git pour fournir des opérations de référentiel de haut niveau pour le modèle de branchement de Vincent Driessen.

Twgit se décrit comme suit:

Twgit est un outil d'aide gratuit et open source pour la gestion des fonctionnalités, des correctifs et des versions sur les référentiels Git. Il fournit des commandes simples et de haut niveau pour adopter le modèle de branchement décrit dans notre documentation. Système d'exploitation pris en charge: Debian / Ubuntu Linux, Mac OS X.

Les deux outils sont disponibles sur github .

Duran
la source