Une stratégie de fusion comme Git Flow est-elle vraiment un anti-pattern?


30

Mon entreprise utilise Git et utilise un schéma de branchement particulier - le travail est effectué en master et les branches sont réservées pour les versions. Cela fonctionne bien, tant que tout le travail effectué dans une itération arrive dans la branche, mais si un problème de production critique survient, nous devons nous assurer que le travail arrive d'une manière ou d'une autre dans les deux branches.

Dernièrement, nous nous sommes amusés avec ces branches. Cela a été un casse-tête administratif, en veillant à ce que tout le travail se retrouve dans chaque branche, et certains bogues qui ont été corrigés sur une branche ne le font pas en maître jusqu'à ce que quelqu'un le signale, ce qui est préoccupant.

Je suis tombé sur Git Flow il y a quelque temps et je pense que ce serait une solution à notre problème - le code ne percolant pas jusqu'à la sortie, ou tout le long de la descente. Le seul hic, c'est que mon responsable a déclaré que ce type de développement était un anti-modèle - se développant furieusement pendant deux semaines, puis en dépensant trois pour résoudre les conflits de fusion.

Je ne suis pas tout à fait sûr d'être d'accord, et depuis que je l'ai soulevé, le travail a repris comme d'habitude. Ce n'est que récemment que nous avons eu des problèmes majeurs avec cela.

Je voudrais savoir - pourquoi ce type de schéma de développement serait-il considéré comme un anti-modèle? Est- ce vraiment un anti-pattern?


1
La section "Règle 3" de l'ancien blog de Ted Dziuba pourrait aider à illustrer comment cela peut être un anti-modèle.
Isxek

5
OMI, plus vous passez de temps à penser au contrôle de version, plus cela a mal tourné avec l'ensemble de l'utilisateur -> phénomène d'outil en premier lieu.
Erik Reppen

@ErikReppen: Je voudrais éloigner tout le monde du contrôle de version et avoir un processus auquel tout le monde peut s'habituer. De cette façon, nous n'avons pas à nous soucier de choses comme s'il s'agit d'un anti-modèle ou non.
Makoto

6
@Makoto Tout ce qui viole KISS est un anti-modèle, IMO. C'est là que les utilisateurs de VCS ont tendance à me rendre fou.
Erik Reppen

6
Le terme «anti-modèle» est un peu comme «meilleure pratique», en ce sens qu'il sert souvent d'excuse pour que les gens se découragent. N'acceptez pas cette notion si le responsable ne peut pas vous dire clairement quelle expérience il en a et pourquoi elle est mauvaise.
Kyralessa

Réponses:


30

Il se réfère principalement au côté des branches de fonction du modèle. Les branches de fonctionnalités ont été déclarées anti-modèle il y a longtemps lorsque les branches ont duré des mois et que les systèmes de contrôle de version n'ont pas pu fusionner pour leur sauver la vie. Les branches de fonctionnalités qui durent une semaine ou deux ont beaucoup moins de problèmes, surtout si vous fusionnez continuellement de develop la branche de fonctionnalités pendant cette période. Tout ce qui est beaucoup plus long que cela n'est toujours pas recommandé.

Même si vous n'utilisez pas le côté branche de fonctionnalité de git flow, les autres parties sont utiles pour vous assurer d'obtenir des fusions propres et que vos modifications se propagent dans la bonne direction.


3
D'après mon expérience avec les branches de fonctionnalités, ou la façon dont nous les avons faites, il peut y avoir du chagrin avec elles si elles sont autorisées à vivre plus d'une itération. Une règle qui stipule que toutes les fonctionnalités doivent être fusionnées dans l'itération avant la sortie serait bien, pour alléger le chagrin des fusions - et mon garçon, avons-nous eu un sérieux chagrin derrière ces ...
Makoto

6
Mon expérience est que vous pouvez avoir des trucs locaux qui traînent aussi longtemps que vous les gardez fusionnés avec un master récent et / ou que vous les développez selon les besoins.
Jan Hudec

2
@JaHudec ... ou jusqu'à ce que vous ayez deux choses qui traînent et qui sont en quelque sorte contradictoires. Vous devriez toujours avoir un aperçu de ce qui se fait ...
johannes

5
Un peu de lecture à ce sujet, et la référence de Martin Fowler semble indiquer que les branches de fonctionnalités effectuées dans un flux d'intégration continu peuvent fonctionner - si elles sont effectuées en petites bouchées que ce que la plupart des gens envisageraient de faire. Donc, dans un sens, vous avez raison - moins de deux semaines, car une durée de vie sur une branche de fonctionnalité semble appropriée. Je ne vois pas, cependant, comment les branches de fonctionnalités elles-mêmes sont l'anti-modèle.
Makoto

3
Tu as raison. Ils ne sont un anti-modèle lorsqu'ils vivent trop longtemps sans être fusionnés. Parfois, les gens critiquent toujours une idée lorsqu'ils ne se souviennent pas des raisons sous-jacentes.
Karl Bielefeldt

21

La fusion est une chose drôle - moins elle est fréquente, plus elle sera difficile, plus elle sera difficile, plus les gens en auront peur, moins ils le feront.

La solution consiste à ne pas laisser les branches trop s'écarter ou à ne pas utiliser de branches.

Si les gens comprennent cela, vous n'aurez probablement pas beaucoup de problèmes avec la fusion, sinon - peut-être que les succursales ne sont pas une bonne idée sans un peu d'éducation.


1
Non, ne pas utiliser de branches est un non-démarreur. L'autre problème principal serait que le travail peut être effectué à deux endroits différents dans le même code, alors j'espère que nous pourrons également faire quelque chose pour y remédier.
Makoto

12
@makoto, découpler assez souvent des choses dans le code rend les conflits moins fréquents. Il peut s'agir soit d'une simple séparation d'une fonctionnalité en fonctions / classes, soit d'un niveau plus élevé en évitant les hypothèses non documentées entre les modules. Ensuite, les changements deviennent plus localisés.
maxim1000

1
@ maxim1000 Je suis d'accord. Je pense que quelqu'un a dit quelque chose comme "Un VCS est une alternative pauvre à l'architecture modulaire [découplée]"
8DH

+1 pour le premier paragraphe. Et oui, sans éducation, gitflow-like est une impasse
daitangio
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.